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ABSTRACT 


The  goals  of  the  Office  of  Naval  Research  sponsored 
Adaptive  Architectures  for  Command  and  Control  (A2C2) 
research  project  are  to  study  current  and  future  joint 
command  and  control  (C2)  issues  and  develop  theories  about 
adaptive  C2  architectures.  The  project  includes  three  tiers 
of  model-based  human-in-the-loop  experiments  ranging  from 
ones  using  simple,  highly  abstract  computer-based 
simulations  (Tier  I) ,  through  more  complex,  realistic 
simulations  (Tier  II) ,  to  involvement  in  wargames  and 
operational  experiments  (Tier  III) .  Three  Tier  I 
experiments  have  been  conducted  to  date,  and  a  fourth  is  in 
planning.  All  have  employed  the  Distributed  Dynamic 
Decisionmaking  III  simulation,  developed  for  this  type  of 
experiment,  and  all  have  involved  variants  of  the  same 
amphibious  scenario.  The  purpose  of  this  thesis  is  to  help 
the  A2C2  research  team  prepare  for  Tier  II  experiments.  The 
target  platform  for  Tier  II  is  the  Marine  Air  Ground  Task 
Force  (MAGTF)  Tactical  Warfare  Simulator  (MTWS) ,  a  detailed 
and  highly  realistic  stochastic  simulation  designed  to  train 
decision-makers .  The  author  investigated  the  degree  to 
which  Tier  I  techniques  and  procedures  can  be  transitioned 
to  Tier  II/  MTWS  by  adapting  the  A2C2  scenario  to  the  MTWS 
environment.  This  thesis  also  discusses  extracting 
experimental  data  from  MTWS . 
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EXECUTIVE  SUMMARY 


The  goals  of  the  Office  of  Naval  Research  sponsored 
Adaptive  Architectures  for  Command  and  Control  (A2C2) 
research  project  are  to  study  current  and  future  joint 
command  and  control  (C2)  issues  and  develop  theories  about 
adaptive  C2  architectures.  Participants  in  the  A2C2  project 
include  representatives  from  ALPHATECH  Inc . ,  APTIMA  Inc . , 
University  of  Connecticut,  George  Mason  University, 
Carnegie-Mellon  University,  Michigan  State  University,  and 
the  Naval  Postgraduate  School. 

The  project  includes  three  tiers  of  model -based  human - 
in-the-loop  experiments  ranging  from  ones  using  simple, 
highly  abstract  computer-based  simulations  (Tier  I) ,  through 
more  complex,  realistic  simulations  (Tier  II) ,  to 
involvement  in  wargames  and  operational  experiments  (Tier 
III) .  Three  Tier  I  experiments  have  been  conducted  to  date, 
and  a  fourth  is  in  planning.  The  A2C2  project  is  designed 
around  a  model -experiment -model  concept,  which  is  an 
iterative  process  that  bases  the  structure  and  hypotheses  of 
future  experiments  around  the  results  of  previous 
experiments . 

Tier  I  studies  have  been  conducted  at  the  Naval 
Postgraduate  School  since  March  1996,  and  have  involved 
officer-students  from  several  curricula.  Tier  I  studies  are 
conducted  on  a  wargame-like  simulation  called  Distributed 
Dynamic  Decisionmaking  (DDD)  III  that  was  modified 
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specifically  for  the  A2C2  project.  In  Tier  I  experiments, 
each  player  acts  as  the  Decision-maker,  staff,  and  computer 
operator. 

In  addition  to  further  Tier  I  testing,  the  next  phase 
of  the  A2C2  project  involves  initiation  of  Tier  II 
experiments.  The  target  platform  for  Tier  II  experiments  is 
the  Marine  Air  Ground  Task  Force  (MAGTF)  Tactical  Warfare 
Simulator  (MTWS) ,  which  is  a  detailed,  realistic,  stochastic 
simulation  designed  to  train  decision-makers. 

The  basic  scenario  used  in  the  Tier  I  experiments  will 
be  the  foundation  for  the  scenarios  to  be  used  in  the 
initial  Tier  II  experiments.  Because  of  this,  studies  must 
be  performed  to  examine  the  feasibility  of  implementing  Tier 
I  scenarios  on  MTWS.  Additionally,  while  later  Tier  II 
experiments  may  have  dedicated  and  trained  MTWS  operators 
(so  the  decision-makers  do  not  have  to  bear  the  burden  of 
learning  and  operating  the  simulation) ,  the  initial 
experiments  in  MTWS  will  likely  mirror  the  Tier  I 
experiments  in  the  sense  that  the  subjects  of  the  experiment 
will  also  be  the  computer  operators  for  the  simulation. 
This  means  that  steps  need  to  be  taken  to  simplify  certain 
procedures  in  MTWS,  to  accommodate  players  who  may  have 
little  to  no  experience  with  MTWS.  Finally,  since  the 
simulation  will  change,  and  the  complexity  of  the  experiment 
will  increase  during  this  transition,  some  of  the  methods 
used  to  extract  data  from  the  computer  will  be  different. 
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Techniques  for  data  extraction  from  MTWS  will  need  to  be 
established  prior  to  Tier  II  experimentation. 

The  purpose  of  this  thesis  will  be  to  facilitate  the 
transition  of  the  A2C2  research  from  Tier  I  to  Tier  II  by- 
demonstrating  how  the  scenario  used  in  DDD  III  can  be 
developed  in  MTWS.  This  thesis  covers  four  major  areas : 
The  first  demonstrates  how  a  working  version  of  the  A2C2 
scenario  can  be  developed  using  modular  approach  based  on 
text-based  batch  files,  while  the  second  area  describes  how 
the  simulation  would  be  played  in  an  experiment.  The  next 
area  discusses  possible  methods  for  data  extraction  from 
MTWS,  and  the  final  area  discusses  the  tradeoffs  that  must 
occur  in  the  transition  from  DDD  to  MTWS,  including  a 
comparison  of  specific  issues  pertaining  to  each  simulation. 
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I. 


INTRODUCTION 


"The  Adaptive  Architectures  for  Command  and  Control 
(A2C2 )  research  program  is  a  multi-year,  multidisciplinary 
effort  to:  (1)  establish  a  body  of  knowledge  in  current  and 
future  joint  command  and  control,  and  (2)  develop  and  test 
theories  of  adaptive  architectures .  A  guiding  principle  of 
the  A2C2  program  is  that  a  practical  knowledge  of  the 
interactions  between  the  organizational  and  task  (mission) 
structures  is  a  precursor  to  the  design  of  flexible 
organizations."  [Ref  5]. 

A2C2  is  an  Office  of  Naval  Research  (ONR)  funded 
project  that  involves  research  and  representatives  from 
ALPHATECH  Inc.,  APTIMA  Inc.,  University  of  Connecticut, 
George  Mason  University,  Carnegie -Mellon  University, 
Michigan  State  University,  and  the  Naval  Postgraduate 
School . 

A.  BACKGROUND 

A2C2  plans  envision  three  tiers  of  human-in-the-loop 
experiments  that  will  fulfill  the  overall  objectives  of  the 
A2C2  program.  Tier  I,  the  first  phase  of  experimentation, 
involves  controlled  experiments,  many  with  of ficer- students 
at  the  Naval  Postgraduate  School  playing  the  roles  of  Joint 
Task  Force  (JTF)  decision-makers.  Tier  I  uses  the 
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Distributed  Dynamic  Decisionmaking  (DDD)  III  simulation, 
which  was  specifically  modified  for  use  in  A2C2.  Tier  I 
experiments  are  highly  abstract  with  each  human  player 
acting  as  a  decision-maker,  staff,  and  the  computer 
operator.  Tier  II  experiments  are  similar  to  Tier  I,  but 
will  use  a  more  realistic  model  for  the  simulation,  and  will 
expand  on  the  experimental  data  and  hypotheses  generated  in 
Tier  I  experiments.  Finally,  Tier  III  experiments  will 
transition  the  A2C2  project  from  simple  exercises  involving 
officer-students  to  wargames  and  operational  exercises  that 
may  involve  an  actual  JTF  commander  and  the  forces  and 
assets  that  would  -  be  used  in  a  real-world  military 
operation. 

An  overall  goal  of  the  A2C2  project  is  to  eventually 
transition  its  findings  to  actual  military  operations.  This 
is  partially  done  throughout  the  project  using  an  iterative 
approach  designed  around  a  model -experiment -model  concept 
that  exists  within  and  between  each  tier  of  experimentation. 
The  results  and  data  collected  from  each  experiment 
conducted  at  the  Tier  I  level  will  likely  affect  changes  in 
following  experiments.  Additionally,  findings  from  Tier  II 
and  Tier  III  experiments  may  prompt  further  Tier  I  testing. 

B .  CURRENT  STATUS 

To  date,  three  experiments  have  been  conducted  at  the 
Naval  Postgraduate  School,  all  at  the  Tier  I  level.  The  DDD 
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was  used  to  simulate  a  Joint  Task  Force  (JTF)  conducting  an 
amphibious  assault .  Each  experiment  was  conducted  using 
officer-students  at  NPS  as.  the  decision-makers,  and  was 
planned  and  conducted  by  A2C2  researchers  with  assistance 
from  students  who  had  participated  in  prior  experiments. 
The  most  recent  was  Experiment  3,  conducted  at  NPS  in 
November  of  1997. 

1.  Experiments  1  and  2 

Experiment  1  was  conducted  in  March  of  1996 .  The 
objective  of  Experiment  1  was  to  evaluate  the  basic 
experimental  techniques  for  Tier  I,  and  to  gather  an  initial 
set  of  data.  Experiment  1  explored  the  issues  associated 
with  resource  conflicts  between  two  and  three  level  command 
hierarchies.  [Ref.  1] . 

Experiment  2  was  conducted  in  November  of  1996,  and 
built  on  the  results  of  Experiment  1.  In  addition,  it  began 
looking  at  architectural  adaptation,  examining  the  effect  of 
changes  in  mission,  diversion  of  forces,  and  as  the  actions 
of  enemy  forces.  [Ref.  1]  . 

2 .  Experiment  3 

Experiment  3  is  discussed  here  in  more  detail  because 
this  experiment  is  also  being  used,  in  part,  as  the  basis  to 
begin  the  Tier  II  experiments. 

Fifty-four  military  officers  (0-3  to  0-4)  in  the 
Joint  Command,  Control,  Computers  and  Intelligence,  and 
Management  Sciences  curricula  were  assigned  to  six-person 
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teams  representative  of  a  Joint  Task  Force  command 
structure.  [Ref.  5]. 

"Nine  teams  responded  to  an  initial  scenario  that 
simulated  an  amphibious  assault  mission  in  a  six-node 
architecture.  A  trigger  event  was  then  introduced  that 
involved  the  loss  of  approximately  30  percent  of  the 
available  assets.  At  the  end  of  a  planning  session  teams 
were  asked  to  choose  from  one  of  three  architectures:  (1) 
their  former,  six-node  architecture  with  reduced  assets,  (2) 
a  five-node  architecture,  that  was  similar  to  their  original 
architecture,  with  assets  somewhat  better  distributed  for 
the  mission,  or  (3)  an  'optimal'  four-node  architecture, 
quite  different  from  their  original  architecture,  with 
assets  specifically  distributed  for  the  mission's  tasks. 
Each  team  then  engaged  in  two  additional  scenarios,  one  in 
the  architecture  they  choose  and  one  in  another,  in  a 
counter-balanced  design."  [Ref.  5]. 

Experiment  3  evaluates  the  same  issues  as  the  previous 
experiments,  as  well  as  some  new  ones.  The  primary 
hypothesis  investigated  in  Experiment  3  was  that  in  a 
situation  where  teams  are  forced  to  adapt  their  structure, 
given  a  choice,  they  will  choose  the  architecture  that  most 
closely  resembles  the  one  that  they  are  most  recently 
familiar  with  rather  than  the  one  that  is  most  suitable  for 
the  situation  (proximity  vs.  optimality).  [Ref.  1). 
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Preliminary  results  of  Experiment  3  supported  the 
initial  hypothesis,  but  also  brought  some  other  issues  to 
light.  The  data  collected  confirmed  that  some  level  of 
"learning"  was  occurring  in  each  successive  trial.  This 
means  that  the  teams  and  individual  players  become  more 
familiar  with  the  scenario  and  simulation  causing  a  slight 
performance  increase  in  each  trial,  which  is  independent  of 
the  architecture  used.  [Ref.  1].  Normally,  due  to 
counterbalancing,  learning  is  not  a  problem,  but  in  this 
case,  the  possibility  exists  that  it  reflects,  in  part, 
inadequate  mastery  of  certain  skills  required  in  some 
architectures,  but  not  others.  If  so,  it  may  have 
influenced  players'  choices.  The  results  of  Experiment  3, 
including  the  learning  result,  will  be  used  to  develop 
Experiment  4,  which  is  scheduled  for  the  summer  of  1998. 

C.  TRANSITIONING  TO  MTWS 

"The  context  in  which  we  study  architectural  adaptation 
is  Joint  command  and  control,  or  more  precisely  the  Joint 
Task  Force  (JTF)  command  staff.  It  is  therefore  essential  to 
make  sure  that  the  architectural  forms  emerging  from  the 
basic  research  effort,  and  tested  in  experiments,  have  a 
certain  degree  of  face  validity.  The  conduct  of  officers-in- 
the-loop  experiments  at  NPS,  the  progressive  evolution  from 
Tier  I  (DDD)  to  Tier  II  (MTWS)  experimentation  have 
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been  designed  to  achieve  this  transition,  while  maintaining 
a  rigorous  scientific  approach.  "  [Ref  6] . 

In  addition  to  further  Tier  I  testing,  the  next  phase 
of  the  A2C2  experiment  is  the  transition  to  Tier  II.  The 
most  likely  candidate  for  the  Tier  II  experimentation  is  the 
MTWS  simulation.  This  transition  is  likely  to  be  a 
complicated  process.  The  basic  scenario  used  in  DDD  will  be 
the  basis  for  the  scenarios  that  will  be  used  in  the  initial 
Tier  II  experiments.  Because  of  this,  feasibility  studies 
need  to  be  performed  that  verify  MTWS'  suitability  to  the 
task.  Additionally,  while  later  Tier  II  experiments  may 
have  dedicated  and  highly  trained  MTWS  operators  (so  the 
decision-makers  do  not  have  to  bear  the  burden  of  learning 
and  operating  the  simulation) ,  the  initial  experiments  in 
MTWS  will  likely  mirror  the  Tier  I  experiments  in  the  sense 
that  the  subjects  of  the  experiment  will  also  be  the 
computer  operators  for  the  simulation.  This  means  that 
steps  need  to  be  taken  to  simplify  certain  procedures  in 
MTWS  to  ensure  that  it  can  accommodate  players  who  will  most 
likely  have  little  to  no  experience  with  MTWS.  Finally, 
since  the  simulation  will  increase  the  realism  and 
complexity  of  the  experiment,  and  since  MTWS  data  collection 
processes  are  different  from  DDD's,  methods  used  to  collect 
data  will  have  to  change.  Techniques  for  data  extraction 
from  MTWS  will  need  to  be  established  prior  to  Tier  II 
experimentation. 
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The  purpose  of  this  thesis  will  be  to  facilitate  and 
explore  this  transition.  A2C2  Experiment  3  is  the  model 
used  for  scenario  development  in  MTWS.  This  is  done  in  four 
major  segments:  MTWS  scenario  development,  execution,  data 
extraction,  and  evaluation. 

The  remainder  of  this  thesis,  starting  with  Chapter  II, 
explores  the  methodology  used  to  build  the  A2C2  scenario  in 
MTWS.  This  will  primarily  be  done  by  using  text  based  batch 
files  that,  when  used  in  a  modular  approach,  make  the 
building  and  modification  of  the  various  architectures  used 
in  Experiment  3  a  simpler  process.  The  process  of 
configuring  MTWS  workstations  for  use  in  the  A2C2  scenario 
is  discussed  in  Chapter  III.  Chapter  IV  evaluates  the 
actual  gameplay  of  the  scenario  in  MTWS  and  the  issues  that 
needed  to  be  confronted  to  overcome  the  complexity  of  the 
MTWS  interface.  An  overview  of  possible  data  extraction 
schemes  is  provided  in  Chapter  V.  As  part  of  the  transition 
process.  Chapter  VI  highlights  some  of  the  differences 
between  MTWS  and  DDD  in  terms  of  issues  that  are  important 
to  the  A2C2  experiment,  and  finally.  Chapter  VII  provides 
recommendations  and  conclusions  to  continue  this  transition. 

D.  TERMINOLOGY 

Certain  terminology  used  in  this  document  has  specific 
meanings  that  should  be  clarified  to  avoid  confusion. 
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1. 


Forces 


The  terms  blue  and  red  forces  generally  refer  to 
friendly  and  enemy  forces  respectively.  Blue  forces,  in  the 
context  of  this  document  and  the  A2C2  experiment  also  refer 
to  the  forces  that  will  be  manipulated  by  the  participants 
of  the  experiment . 

2.  Simulation  vs.  Scenario 

Scenario  is  used  to  refer  to  the  operational  mission 
that  is  the  focus  of  the  A2C2  experiment.  The  operation 
plan  of  the  A2C2  scenario  is  outlined  in  detail  in  Appendix 
D.  Simulation  refers  to  the  specific  implementation  of  the 
A2C2  scenario  in  MTWS . 

3 .  Players 

Players,  in  this  document  refers  to  the  individuals  who 
are  participating  as  subjects  in  the  A2C2  experiment. 
Operators  are  the  individuals  who  actually  operate  the 
terminals.  The  simulation  was  developed  so  the  participants 
could  act  as  both  players  and  operators,  even  though  this  is 
not  necessary.  Chapter  V  discusses  this  in  more  detail. 

4.  MTWS  Terms 

MTWS  Station  Control  (MSC)  refers  to  the  computer  that 
is  acting  as  the  primary  server  for  the  MTWS  simulation. 
MTWS  Display  Stations  (MDS)  are  the  individual  computers  in 
the  MTWS  network  that  provide  the  actual  interface  for  the 
game  players . 
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5. 


MTWS  Instructions 


During  the  course  of  this  document,  there  are  often 
references  to  specific  windows  and  menu  operations.  A 
window  is  referenced  by  its  title  which  appears  in  the 
center  of  the  very  top  of  the  window.  MTWS  contains  many 
menu  options  nested  inside  other  menus.  When  referencing 
multiple  menu  operations,  the  notation  MENU->SUBMENU1- 
>SUBMENU2 - >OPTION  means  that  the  option  or  function  that  is 
referenced  is  actually  two  menus  deep.  Certain  files  on  the 
MTWS  server  are  often  listed  in  this  document.  When  they 
are  mentioned  directly  in  the  text,  they  will  appear  in 
quotes . 
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II.  BUILDING  THE  MTWS  SCENARIO 


This  section  will  explain  the  initial  steps  required  to 
launch  MTWS,  create  and  start  a  new  scenario  and  use  batch 
files.  It  is  assumed  that  the  reader  has  been  exposed  to 
MTWS  or  has  MTWS  reference  materials  available.  Batch  files 
allow  MTWS  commands  to  be  issued  from  a  file.  Some  are  used 
in  examples,  but  a  complete  listing  of  batch  files  used  in 
this  thesis  and  their  contents  is  located  in  Appendix  A. 
MTWS  source  materials,  such  as  the  MTWS  Training  Handbooks, 
[Ref.  4]  .  provide  more  detail  on  the  specifics  of  MTWS 
commands  and  are  available  in  the  Systems  Technology  Lab 
(STL) . 

A.  CREATING  AND  INITIALIZING  THE  NEW  SCENARIO 

After  initializing  MTWS,  as  described  in  Appendix  F, 
select  the  CREATE  option  using  the  computer  configured  as 
the  MTWS  System  Controller  (MSC) .  This  option  is  available 
in  the  MTWS  Systems  Operations  window  under  the  Exercise 
Control  menu,  in  the  DATABASE- >  EXERCISE  submenu.  The 
window  that  pops  up  as  a  result  of  the  CREATE  command 
contains  several  critical  options.  The  new  scenario  must  be 
given  a  unique  name  (one  that  doesn't  exist  locally  on  the 
MTWS  network) ,  a  start  time  is  specified  if  needed,  and  a 
user  defined  parametric  database  is  selected.  Since  the 
A2C2  experiment  has  special  requirements,  a  previously 
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modified  version  of  the  MTWS  parametric  database  created 
specifically  for  the  A2C2  experiment  must  be  selected. 
Details  of  creating  and  modifying  the  parametric  database 
appear  at  the  end  of  this  chapter.  Select  USER  DEFINED  from 
the  list  of  options,  and  another  window  will  open  that  lists 
the  available  customized  databases.  Select  the  appropriate 
database.  For  this  experiment  select  the  database  called 
A2C2_DATA.  The  user  defined  parametric  database  must  be 
defined  and  saved  before  the  scenario  is  created.  Anytime 
modifications  are  made  to  the  parametric  database  the 
scenario  must  be  created  again.  Each  time  a  scenario  is 
created,  it  makes  its  own  copy  of  the  parametric  database. 
No  topographic  data  is  specified  for  the  A2C2  scenario, 
because  in  this  implementation  of  the  scenario,  a  flat  earth 
model  is  used. 

The  scenario  start  date  and  time  is  user  selectable, 
and  should  be  considered  carefully.  Once  the  start  time  has 
been  selected,  the  system  clock  can  only  be  moved  ahead, 
never  backwards.  It  is  important  to  know  the  system  time 
because  many  of  the  batch  files  used  in  the  scenario  to 
automate  the  actions  of  the  red  forces  are  triggered  at  a 
specific  time;  they  will  not  execute  until'  the  specified 
time  occurs  in  the  scenario.  The  new  exercise  can  now  be 
loaded  using  the  LOAD  option.  The  parametric  database  will 
load,  and  the  system  clock  will  be  set  to  the  selected  start 
time. 
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The  next  steps  create  both  the  artificial  and  natural 
terrain  features  and  then  the  friendly  and  enemy  units  used 
in  the  scenario.  The  items  created  can  be  added  to  the 
scenario  in  one  of  two  ways:  direct  changes  to  the  scenario 
or  batch  files. 

1.  Direct  Changes 

The  first  method  of  building  or  modifying  an  exercise 
involves  loading  the  scenario  and  then  modifying  the 
scenario  by  manually  issuing  commands  through  they  keyboard. 
Once  the  desired  units  and  assets  are  in  place,  issue  the 
SAVE  option  under  the  same  submenu  as  the  LOAD  command. 
Because  of  the  requirements  of  the  A2C2  experiment,  this 
method  is  not  the  best  method.  A  unique  scenario  would  have 
to  be  created  for  each  architecture  used,  a  time  consuming 
and  error  prone  process . 

2 .  Creating  Batch  Files 

MTWS  has  a  powerful  scripting  utility  that  allows  a 
user  to  easily  create  batch  files  that  can  contain  commands 
within  the  file  to  set  up  a  scenario  or  automate  the 
simulation.  Invoking  the  file  name  causes  these  commands  to 
be  executed.  This  is  the  recommended  method  for  building 
scenarios  for  the  A2C2  experiment.  Since  the  A2C2 
experiment  requires  as  many  as  six  architectures,  and  all 
the  architectures  bear  some  similarities  to  the  others,  it 
makes  sense  to  use  a  modular  approach  to  building  these 
scenarios.  For  each  unit  needed  in  an  architecture,  a 
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unique  batch  file  is  created  that  will  automatically  define 
this  unit.  If  similar  units  are  required  for  other  players, 
or  multiples  of  the  same  unit  are  needed  for  one  player,  the 
initial  batch  file  can  simply  be  copied  and  modified  to 
reflect  the  characteristics  of  the  new  unit. 

B.  WORKING  WITH  BATCH  FILES 

This  section  describes  how  batch  files  are  used  to 
build  an  MTWS  scenario.  The  use  of  batch  files  is 
especially  useful  for  the  A2C2  application  because  of  the 
ease  with  which  custom  scenarios  can  be  built  around  the 
core  mission  described  in  the  experiment .  Because  of  the 
large  number  of  files  required  for  this  experiment,  it  is 
important  to  have  a  comprehensive  batch  file  naming 
convention  to  avoid  confusion.  The  following  examples  show 
how  batch  files  are  built  and  how  each  one  is  named. 

1.  Batch  File  Names 

Figure  1  lists  a  sample  set  of  batch  files  containing 
complete  MTWS  commands  that,  when  invoked,  create  the 
infantry  units  required  for  the  scenario.  The  remainder  of 
this  section  describes  the  batch  file  naming  convention  used 
in  A2C2 .  The  following  section  describes  how  to  build  batch 
files.  The  first  batch  file  on  the  list  is 
"a2c2_p4_infl_p4_lhal. "  The  a2c2  prefix  is  included  in  all 
the  batch  files  that  were  used  to  develop  this  scenario  in 
order  to  distinguish  them  from  the  hundreds  of  other 
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miscellaneous  files  that  reside  in  the  same  directory.  If 
desired,  the  default  directory  for  batch  files  can  be 
changed  by  modifying  a  file  called  "/mtws/mds/ .profile" . 
Edit  that  file  and  change  the  parameter  called  CE_BATCH_PATH 
to  the  desired  path. 

The  second  part  of  the  file  name  is  p4 .  This  space  is 
reserved  for  the  owner  of  the  unit,  in  this  case,  p4,  or 
Player  4.  There  are  six  possible  players  in  the  A2C2 
scenario,  p0-p5.  The  third  part  of  the  filename  is  inf 2 . 
This  refers  to  p4 '  s  second  infantry  unit .  Note  that  in 
Figure  1,  p2  also  has  an  inf2.  During  simulation  play,  unit 
names  will  include  the  player  number  as  a  prefix  so  they  can 
be  easily  distinguished.  Finally,  the  last  2  parts  of  the 
filename  are  p4_lhal.  This  simply  indicates  the  initial 
position  of  the  infantry  unit,  in  this  case  on  player  4's 
LHA.  If  a  unit's  initial  position  is  not  located  on  another 
asset,  no  location  will  be  specified  in  the  batch  file  name. 
For  instance,  if  a  unit  were  to  be  placed  in  the  field,  its 
batch  file  name  would  be  "a2c2_p4_inf 2 . " 

Since  the  unit's  initial  position  is  located  on  another 
asset  (LHA1)  ,  it  is  important  that  the  file  defining  player 
4's  LHA  is  defined  and  invoked  prior  to  the  infantry  unit's 
creation.  The  batch  file  "a2c2_p4_lhal"  must  be  invoked 
before  "a2c2  p4  inf 2  p4  lhal" .  In  some  architectures. 
Player  4  requires  another  infantry  unit  to  be  placed  on  the 
same  ship.  The  file  "a2c2  p4  infl  p4  lhal"  is  then  copied 
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The  contents 


to  a  new  file  called  "a2c2_p4_inf 2_j>4_lhal .  " 

of  the  new  file  need  to  be  modified  as  well.  In  this  case 

all  the  instances  of  infl  would  need  to  be  changed  to  inf 2. 

This  illustrates  how  easily  and  accurately  similar  units  can 

be  created  when  compared  with  the  tedious  manual  method. 

a2c2_p4_inf 2_p4_lhal 
a2c2_p4_inf 2_p2_lpdl 
a2  c2_p4_inf  l__p4_lhal 
a2 c 2_p4_inf l_p2_lpdl 
a2c2_j?3_inf  5_p2_lhal 
a2c2_p3_inf4_p2_lhal 
a2 c 2_p3_inf 3_p2_lpdl 
•  a2c2  jp3_inf 2_p2_lpdl 
a2c2_p3_infl_p3_lpdl 
a2c2_jp3_inf  l_p2_lpdl 

_ a2c2  p2  infl  p2  lhal _ 

Figure  1.  Sample  list  of  batch  files  to  create  units. 


The  examples  listed  so  far  are  for  defining  units. 
These  types  of  batch  files  are  only  used  once,  at  the  time 
the  simulation  is  loaded.  Certain  other  batch  files  will  be 
used  by  players  while  a  trial  is  in  progress.  These  batch 
files  will  usually  used  to  automate  tasks  in  MTWS  that  would 
be  too  complicated  or  time  consuming  for  an  A2C2  player  to 
input  manually.  These  include  such  tasks  as  launching  an 
air  mission,  or  transporting  infantry  units  from  ship  to 
shore.  The  names  of  these  types  of  batch  file  start  with  a 
word  that  indicates  their  function  followed  by  additional 
information  that  describes  the  players  that  control  the 
assets  and  the  unit  identification.  Figure  2  shows  a 
listing  of  batch  files  for  creating  and  launching  various 
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Close  Air  Support  (CAS)  units.  The  first  line  is  the  name 

of  the  file  that  would  launch  player  one's  first  CAS  unit, 

which  is  called  P1_CAS1. 

a2c2_launch_pl_casl 

a2c2_launch_p3_casl 

a2c2_launch__p4_casl 

a2c2_launchjp4_cas2 

a2c2_launch_p5_casl 

Figure  2 .  Sample  batch  files  to  be  used  by  players.  ” 

2 .  Recording  a  Batch  File 

Batch  files  are  assigned  to  the  MTWS  Display  Station 
(MDS)  that  creates  them.  The  LOG  menu  item  located  at  the 
top  of  the  Command  Entry  window  is  used  for  recording  and 
saving  batch  files.  The  OPEN  command  is  selected  under  this 
menu,  in  order  to  start  MTWS  recording  commands.  MTWS  will 
prompt  the  user  for  a  unique  filename.  Since  the  technique 
used  to  develop  the  MTWS  scenario  requires  such  a  large 
number  of  batch  files,  it  is  wise  to  adhere  to  the  naming 
convention,  such  as  the  one  outlined  in  the  previous  section 
and  shown  in  and  Figure  2 .  Appendix  A  contains  complete 
listings  of  all  names  and  contents  of  batch  files  used  in 
this  particular  A2C2  scenario. 

Once  a  log  file  has  been  opened,  MTWS  will  append  every 
successful  command  issued  on  the  MDS  that  opened  the  log 
file  into  that  batch  file.  If  a  command  is  rejected  for  any 
reason,  it  will  not  be  stored  in  the  batch  file. 
Additionally,  only  commands  issued  in  the  Command  Entry 
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Window  for  that  MDS  will  be  logged.  Adjustments  to  the  map 
settings  or  any  other  windows  will  not  be  recorded. 

Once  the  batch  file  is  complete,  the  user  can  select 
the  CLOSE  option  from  under  the  LOG  menu.  When  this  process 
is  completed,  the  resulting  batch  file  is  stored  in  the 
/mtws/db/cmd_entry/batch/  directory.  Figure  3  shows  an 
example  of  the  contents  of  a  batch  file.  The  following 
sections  will  explain  how  various  types  of  MTWS  batch  files 
are  constructed  and  structured. 

CE; CONSTRUCT ;RD1 ; ; ; IMPROVED_SURFACE; ROAD; ASPHLT-2-LANE ; {1352SEQ325127; 
52SEQ324121;52SEQ317117;52SEQ309120;52SEQ305117;52SEQ303114;52SEQ292105/ 

52SEQ2 69104 ;52SEQ2 63102 ; 52SEQ255087; 52SEQ222069; 52SEQ2 19066; 52SEQ2 1002 6; } $ 

C  E ; C REAT  E ; H I LL ; NATURA1_T ERRAI N ; MOUNT AI N ; MOUNTAI N ; { 0652SEQ284 12 6;52SEQ276122 ; 
52SEQ275115;52SEQ284111;52SEQ294116; 52SEQ292125; } $ 

CE ; CREATE ; PORT ; STRUCTURE ; PORT-  FAC I LITY ; 5  2  SEQ3 1 5 1 1 6 ; 15 ; 4  0 ; 1 0  0 ; $ 

Figure  3 .  Contents  of  a  batch  file. 

a)  Creating  Terrain 

Actual  Digital  Terrain  Elevation  Data  (DTED)  can 
be  used  in  MTWS,  but  for  the  purposes  of  the  A2C2 
experiment,  it  is  not  implemented  since  the  geographical 
layout  in  the  scenario  is  mostly  fictitious.  The  elevation 
data  would  not  necessarily  be  consistent  with  the  terrain 
features  created  specifically  for  this  A2C2  scenario  and 
could  cause  confusion  for  the  players. 

Figure  4  shows  an  approximate  layout  that  was  used 
for  the  A2C2  scenario.  Once  an  appropriate  geographical 
setting  has  been  selected,  the  MTWS  user  can  start  creating 
terrain  features.  The  interface  for  creating  terrain  is  the 
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same  interface  used  to  manipulate  units  and  create  missions. 
All  the  commands  and  options  to  create  man-made  or  natural 
terrain  features  are  located  under  the  CE-CREATE  and  CE- 
CONSTRUCT  menu  items  under  the  command  menu.  The  CE-CREATE 
function  is  generally  used  to  create  natural  terrain 
features,  such  as  rivers  and  hills,  while  the  CE-CONSTRUCT 
option  can  also  build  other  features  such  as  roads  or 
obstacles,  such  as  minefields  or  antitank  ditches.  If  an 
existing  unit  is  specified  in  the  CE-CONSTRUCT  command  then 
MTWS  will  simulate  the  actual  construction  process. 
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To  create  Road  1,  as  shown  in  Figure  4,  the  CE- 
CONSTRUCT  command  is  selected.  The  resulting  dialog  box 
includes  the  object  name,  RD1 .  Several  optional  parameters 
are  listed  for  this  command,  and  in  this  particular  case, 
these  parameters  were  left  blank.  The  next  option  is  the 
selection  of  the  type  of  structure  that  is  to  be 
constructed.  In  this  case,  IMPROVED  SURFACE  was  chosen,  the 
type  was  selected  as  ROAD,  and  the  sub-category  was  chosen 
as  ASPHLT-2-LN.  The  final  option  was  to  select  the  sequence 
of  points  that  the  road  is  to  follow.  These  coordinate 
values  could  be  manually  entered,  but  the  most  efficient  way 
is  to  enter  these  values  by  clicking  the  cursor  on  the  map 
window  at  the  desired  location.  Once  the  points  for  the 
road  have  been  selected,  the  user  presses  the  transmit 
button,  the  command  is  processed,  and  the  entry,  shown  in 
Figure  5,  is  made  in  the  log  file. 

In  the  batch  file  structure,  a  semicolon  separates 
each  option  that  was  input  by  the  user.  In  the  case  of 
optional  fields  that  were  left  blank,  a  semicolon  is  still 
inserted  in  the  batch  file  to  act  as  a  place  holder  for  that 
particular  option.  The  options  that  are  shown  in  the  file 
are  exactly  as  they  appeared  in  the  dialog  box.  Thirteen 
points  for  RD1  are  listed  in  this  box  using  MTWS '  coordinate 
system.  Since  multiple  points  could  be  selected  for  the 
road  location,  these  points  appear  inside  brackets.  The 
very  first  point  is  prefixed  by  the  number  13.  This  is  to 
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tell  MTWS  that  thirteen  data  points  follow.  When  editing 
batch  files  manually,  it  is  very  important  to  make  sure  this 
prefix  represents  the  actual  number  of  data  points.  For 
example,  the  user  may  have  decided  to  take  out  a  certain 
bend  in  the  road  by  removing  two  points .  The  13  must  be 
reduced  to  11  to  account  for  the  points  that  have  been 
removed.  Many  commands  in  MTWS  treat  multiple  data  points 
using  this  convention,  including  flight  routes,  unit  asset 
updates,  and  ground  troop  movements  and  missions.  Since  a 
single  batch  file  command  usually  takes  up  multiple  lines  of 
text,  the  end  of  the  command  is  denoted  by  a  "$". 

CE;  CONSTRUCT; RDl; ; ; IMPROVED_SURFACE; ROAD; ASPHLT-2 -LANE ; { 1352SEQ325127; 

52SEQ324121;52SEQ317117;52SEQ309120;52SEQ305117;52SEQ303114;52SEQ292105; 
52SEQ269104;52SEQ263102;52SEQ255087;52SEQ222069;52SEQ219066;52SEQ210026; }$ 

Figure  5.  Log  of  a  CE- CONSTRUCT  command  to  create  a  road. 

Since  the  terrain  features  in  this  A2C2  experiment 
are  unchanged  between  the  different  trials,  are  the  terrain 
commands  were  created  in  one  large  batch  file  called 
"a2c2_create_terrain. " 

b)  Creating  Units 

A  similar  process  is  used  to  create  ground,  sea, 
and  air  units.  From  the  Command  Entry  Window,  the  Ground - 
Unit -Define  menu  option  is  chosen.  The  user  is  prompted  for 
information  regarding  the  unit,  including  whether  they  want 
to  use  the  Table  of  Organization  and  Table  of  Equipment 
(TO/TE)  database  that  is  included  with  MTWS.  The  TO/TE 
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database  includes  predefined  unit  asset  listings  for  various 
friendly  and  enemy  units  at  all  levels  of  command.  In  the 
case  of  the  blue  forces  in  this  experiment,  the  TO/TE  is 
almost  always  used.  The  command  to  create  an  infantry  unit 
that  is  used  in  this  scenario  would  be  logged  in  a  batch 
file  as  shown  in  Figure  6 . 

UNIT; DEFINE; P4_INF2  ;LF;  INFANTRY;  PLATOON;  P4_LHA1  ;MANC0N_5 ;  ;  SIMULATED;  FALSE; 

YES ; USMC ; I FY_3 ; $ 

Figure  6.  Sample  batch  file  created  from  a  command  to 
define  an  infantry  unit. 

This  batch  file  is  the  contents  of  the  first  file 
listed  in  Figure  1.  Like  the  example  file  that  defined  a 
road,  each  option  is  separated  by  a  semicolon.  If  this  file 
is  used  as  the  basis  for  other  batch  files  that  create 
infantry  units,  the  parameters  that  must  be  changed  are 
P4_INF2  (name) ,  P4JLHA1  (location) ,  and  MANC0N_5 
(controller) .  The  location  in  this  case  is  a  ship,  but  map 
coordinates  can  also  be  used  in  this  field.  The  eighth 
parameter  in  the  batch  file  in  Figure  6,  is  MANC0N_5.  This 
parameter  is  the  controller  assigned  to  the  unit.  In  this 
experiment,  each  player  is  assigned  a  specific  controller. 
MANC0N_1  through  MANC0N_6  are  the  controllers  for  players  0 
through  5.  The  controller (s)  assigned  to  a  specific  player 
will  determine  which  unit-specific  information  is  directed 
to  each  player.  If  a  player  controls  P2_INF1,  this  infantry 
unit  will  need  to  be  assigned  to  MANC0N_3 .  Any  computer 
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generated  reports  regarding  P2_INF1  will  be  directed  to  all 
stations  that  have  been  assigned  MANC0N_3  as  a  controller. 
This  will  be  discussed  in  greater  detail  in  Chapter  III. 

c)  Predefining  Air  Missions 

Individual  aircraft  are  not  considered  units  in 
MTWS.  Rather,  they  are  assets  that  may  be  allocated  to  a 
particular  air  squadron.  To  ensure  that  an  air  mission  can 
be  executed  during  an  MTWS  scenario,  several  things  must 
occur  first.  An  air  squadron  as  well  as  fuel  and  support 
squadrons  need  to  be  defined  and  positioned  where  the 
airfield  is  to  be  located.  These  are  all  defined  using  the 
GROUND- >UNIT->DEFINE  under  the  COMMAND  menu  option  in  the 
Command  Entry  window.  For  the  sake  of  simplicity  in  this 
experiment,  the  same  squadron  is  used  for  the  air  support 
and  air  fuel  squadrons.  Ordinance  loads  also  need  to  be 
defined  using  the  AIR- >ORDINANCE  LOAD->DEFINE  menu  item. 
The  ordinance  loads  in  MTWS  only  define  a  template  for  the 
types  and  amount  of  ordinance  needed  for  an  air  mission,  and 
not  the  actual  load  itself.  Only  one  ordinance  load  needs 
to  be  defined  for  each  type  of  armed  air  mission  to  be 
flown.  The  fuel/supply  unit  will  need  enough  fuel  and 
weaponry  to  support  all  the  air  missions  that  will  be  flown 
from  that  location  during  the  trial .  Fuel  and  assets  are 
added  using  the  GROUND- >UNIT->UPDATE  command.  An  airfield 
can  now  be  defined  using  the  COMMAND- >AIRFIELD->DEFINE  menu 
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option  and  filling  in  the  appropriate  information.  In  the 
A2C2  experiment,  all  of  the  friendly  airstrips  are  located 
on  ships.  The  airfield  must  have  the  same  name  as  the  ship 
in  order  for  MTWS  to  function  properly. 

Figure  7  shows  the  batch  file  that  defines  an 
aircraft  carrier  as  well  the  collocated  airfield.  In  this 
sample,  there  are  no  aircraft  defined.  Aircraft  are 
allocated  using  separate  batch  files.  Since  the  number  and 
type  varies  with  each  mission,  a  batch  file  has  been  created 
for  each  pair  of  aircraft  to  be  used. 


UNIT; DEFINE ; P1_CV1 ; LF; SHIP ; COMPANY; 52SEQ35  4  037 ;MANC0N_2 ; ; SIMULATED ; FALSE ; 
YES ; USN ; JFK_CLAS S ; $ 

UNIT; DEFINE; P1_CV1_AIRSUPPLY; LF; SUPPLY; COMPANY; P1_CV1 ; AIRCON; ; SIMULATED; 
FALSE; YES;USMC;MAT_SUP; $ 

UNIT; DEFINE; P1_CV1_AIRSQUAD;LF;AIR_SQUADR0N; SQUADRON; P1_CV1; AIRCON; ; 

S IMULATED ; FALSE ; YES ; USMC ;VMAAW; $ 

AIRFIELD; DEFINE ; P1_CV1 ; P1_CV1 ; OPEN; P1_CV1_AIRSUPPLY; P1_CV1_AIRSUPPLY; 

{ 01P1_CV1_AIRSQUAD; } {00; }$ 

AS SETS; UPDATE; P1_CV1_AIRSQUAD; ASSET; {04MK-84-BOMB;500;OPERATIONAL; 

ZUNI -RKT-4 ; 5  0  0 ; OPERAT I ONAL ; 2  OMM-HE-AC ; 1 0  0  0  0  0 ; OPERATIONAL ; MAVERICK- TV-MSL; 
500; OPERAT I ONAL ; } $ 


Figure  7.  Batch  file  that  defines  an  aircraft  carrier  and 

airfield. 


In  the  A2C2  experiment,  all  combat  aircraft  are 
operated  in  units  of  two.  The  batch  file  "a2c2_pl_casl" 
defines  and  allocates  two  F18s  to  the  air  squadron  on  the 
aircraft  carrier.  While  several  batch  files  exist  to  define 
CAS  aircraft  for  different  players,  there  is  actually  no 
difference  in  contents  of  these  files.  Separate  batch  files 
for  CAS  with  distinct  file  names  were  created  only  to 
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facilitate  use  by  the  person  who  is  required  to  build  a 
specific  architecture  using  these  batch  files. 

Once  all  the  requisite  units  have  been  defined, 
the  air  missions  can  be  defined.  Batch  files  to  launch  each 
aircraft  unit  were  created  to  ease  this  process  for  the 
players.  If  Player  4's  CAS  unit  needs  to  be  launched,  the 
batch  file  called  a2c2  launch  p4_casl  is  executed.  This 
file  will  execute  the  instruction  shown  in  Figure  8.  Note 
that  this  air  mission  is  defined  with  the  same  name  as  the 
unit  it  represents  (P1_CAS1) . 

Since  ,  close  air  support  (CAS)  was  used  in  the 
mission  type  in  Figure  8 ,  a  supported  unit  was  required  by 
MTWS  for  this  mission.  The  unit  P5_ENG  was  used,  but  any 
friendly  ground  unit  could  have  been  used  here.  Setting 
this  option  does  not  preclude  the  air  mission  from 
supporting  another  ground  unit.  The  last  portion  of  this 
command,  enclosed  in  brackets,  defines  the  actual  route  of 
the  air  mission.  In  this  case,  the  purpose  is  only  to 
launch  the  aircraft,  so  a  way-point  close  to  the  launch  site 
was  chosen,  and  the  aircraft  was  put  into  a  medium  orbit. 
The  aircraft  will  continue  to  orbit  until  the  player 
controlling  it  issues  an  AIR->MISSION->DIVERT  command. 
Chapter  III  will  discuss,  in  more  detail,  how  air  missions 
are  controlled  by  the  players. 
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AI R_MI S  S I ON ; DE  F INE ; P 1_CAS 1 ; FA- 1 8 ; 2 ; P 1_CV1_AI RS  QUAD ; P 1_CV1 ; ; ; 

P5_ENG; CAS ;CAS_ORD; ; ; FALSE; TAKE_OFF; ; { 0152SEQ334  058 ;MEDIUM; ORBIT; } $ 

Figure  8.  Defining  an  air  mission.  "™~~ 

d)  Ship  to  Shore 

Most  of  the  ground  units  used  in  the  A2C2  scenario 
are  initially  positioned  onboard  ships.  MTWS  requires  a 
series  of  commands  to  be  executed  in  order  to  airlift  a  unit 
from  a  ship  to  a  specified  location  on  the  ground.  This 
series  requires  three  commands.  AIR  MISSION- >DEFINE/  STS- 
>SERIAL- >DEFINE ,  and  STS->SERIAL->ASSOCIATE  under  the 
COMMAND  menu  option  in  the  Command  Entry  window.  A  serial 
is  a  ship  to  shore  operation  that  involves  transport  of 
cargo,  assets,  or  troops.  A  serial,  in  this  example,  is 
defined  in  terms  of  a  predefined  air  mission  and  an  existing 
ship.  This  sequence  and  the  example  shown  in  Figure  9, 
assumes  that  the  prerequisites  for  an  air  mission,  similar 
to  the  one  described  in  the  previous  section  and  in  Figure 
7,  have  already  been  met.  It  also  assumes  that  beaches  with 
landing  zones  have  been  defined.  In  MTWS,  a  beach  is  not  a 
terrain  item.  Instead  it  is  a  logical  construct  used  for 
planning  purposes  and  for  defining  missions.  Because  of 
this,  the  option  to  define  a  beach  is  located  under  the  STS 
(ship- to- shore)  menu  item. 

Along  with  the  beaches,  checkpoints  also  need  to 
be  defined.  Figure  10  shows  the  batch  file  to  define  the 
beaches  and  checkpoints.  The  user  is  prompted  for  beach 
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start  points  and  end  points,  as  well  as  a  line  of  departure, 
a  causeway,  and  start  and  stop  points  for  the  underway 
launch  line.  Since  most  of  these  parameters  do  not  factor 
heavily  into  this  exercise,  but  are  required  for  MTWS  to 
accept  the  BEACH- >DEFINE  command  and  to  display  it  on  the 
map.  Chapter  IV  provides  an  overview  on  MTWS  usage, 
including  how  to  turn  off  various  display  items,  including 
the  beach  geometries. 

When  a  checkpoint  is  defined,  it  must  also  be 
specified  as  a  landing  zone.  To  define  a  serial,  a  landing 
zone  parameter  is  required,  and  the  command  will  not  be 
accepted  until  a  landing  zone  has  been  specified.  In  this 
scenario,  the  checkpoints  for  the  two  beaches  were  SB  and  NB 
(South  and  North  Beaches) ,  and  these  are  referenced  in  the 
SERIAL- >DEFINE  command  shown  in  Figure  9. 

AI R_MI S  S I ON; DE  FI NE ; LHA_LAND_P2_INF1_SB; MV- 2  2 ; 1 ; 

P  2_LHA1_AI RS QUAD ; P2_LHA1; ; ; ; STS ;  TAKE_OFF; ; { 01SB; MEDIUM; UNIT_DROP; } $ 

SERIAL; DEFINE ; LHA_LAND_P2_INF1_SB; LF; P2_LHA1 ;USE_OF_AIRCRAFT ; {01P2  INF1; }SB; 
MV-22;1;$  ” 

SERIAL; ASSOCIATE; LHA_LAND_P2_INFI_SB; LHA_LAND_P2_INF1_SB; $ 

Figure  9 .  Transferring  a  unit  from  ship  to  shore . 


BEACH; DEFINE ;SOUTH_BCH;LF; 5 2SEQ23 000 6 ;52SEQ2 45020; ; ;52SEQ232004; 52SEQ249016; 
S2SEQ237015; { 0352SEQ252014; 52SEQ236002;52SEQ252004; } ; ; ; $ 

BEACH; DEFINE ;N0RTH_BCH; LF;52SEQ2 680 65 ;52SEQ28 9074; ; ;52SEQ2 69061 ;52SEQ292071; 
52SEQ279073; {0352SEQ275060;52SEQ293066;52SEQ289054; };; ;$ 

CHECKPOINT ; DEFINE ;NB;52SEQ2 7 6071 ;LF; YES; $ 

CHECKPOINT; DEFINE; SB; 5 2SEQ235 012 ;LF; YES; $ 


Figure  10.  Defining  a  beach. 
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e)  Creating  Red  Forces 

In  this  exercise,  enemy  forces  are  created  in  a 
similar  manner  to  blue  forces,  but  are  fully  automated.  In 
many  cases,  the  automation  is  a  default  MTWS  behavior.  Any 
unit  (including  a  blue  unit)  will  automatically  try  to 
defend  itself  if  threatened  or  attacked  by  an  opposing 
force.  Ground  units  can  also  be  defined  and  put  in  a 
defensive  posture  (which  increases  their  defensive 
capability)  or  they  can  be  moved  automatically  at  specific 
times. 

One  portion  of  the  exercise  requires  blue  forces 
to  identify  trucks  moving  along  two  different  roads.  The 
trucks  are  timed  to  appear  in  2-3  minute  intervals.  This  is 
done  by  issuing  a  GROUND- >UNIT- >MISSION  command.  Most 
mission  commands  give  the  user  an  option  to  specify  a  start 
time.  These  commands  are  issued  with  a  specific  start  time 
and  are  logged  into  a  batch  file.  The  batch  file  with  these 
time  lagged  commands  is  invoked  at  the  beginning  of  the 
scenario,  but  not  executed  until  the  specified  time.  The 
sample  file  in  Figure  11  shows  the  commands  that  instruct 
the  trucks  to  start  moving  at  certain  times.  These  times 
need  to  be  specified  relative  to  the  simulated  start  time  of 
the  scenario.  If  the  start  time  of  the  exercise  is  changed, 
all  automated  batch  files  need  to  be  updated  as  well.  MTWS 
uses  the  24  hour  time  format,  referenced  to  Greenwich  Mean 
Time  (GMT)  also  known  as  Zulu  time.  For  example, 
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241914ZFEB98  would  1914  hours  (7:14  pm)  on  24  February,  1998 
in  the  Greenwich  London  (Zulu)  time  zone. 

UNIT ; MI S  S I ON ; TRK2 ; MOVE ; COLUMN ; ; MV_PLANS ; NO ; ; ; 2  4 1 9 1 4  Z  FEB  9  8 ; { 0  6RD3 ; ; 5  2  SEQ2 2 1 0 7  8  ; 

; RD 5 / ?  5  2  S  E Q2 1 8  0  6  6 ; ; RD 1 ; ; 5  2  S E Q 2 1 0 0  2  5 ; ; } $ 

UNIT ;MISS ION; TRK4; MOVE /COLUMN; ;MV_PLANS;NO; ; ;241917ZFEB98; {06RD3; ;52SEQ221078; 

; RD5 ; ; 52SEQ218066; ;RD1; ;52SEQ210025 ; ; }$ 

UNIT;MISSION;TRK5;MOVE;COLUMN; ;MV_PLANS;NO; ; ;241920ZFEB98; {06RD3; ;52SEQ221078; 

; RD5 ; ; 52SEQ218066; ;RD1; ;52SEQ210025 ; ; }$ 

UNIT;MISSION;TRK6; MOVE ; COLUMN ; ;MV_PLANS;NO; ; ;241924ZFEB98; {06RD3; ;52SEQ221078; 

; RD5 ; ; 5  2  SEQ2 1 8  0  6  6 ; ; RD1 ; ; 52  SEQ2 10025;;}$ 

UNIT;MISSI ON ; T RK8 ; MOVE ; COLUMN ; ;MV_PLANS;NO; ; ;241927ZFEB98; {06RD3;;52SEQ221078; 
;RD5;;52SEQ218066;;RD1;;52SEQ210025;;}$ _ 

Figure  11.  Instructions  for  automated  unit  movements. 

During  the  A2C2  scenario,  various  enemy  units, 
usually  artillery,  will  appear  and  disappear  on  the  display 
to  simulate  enemy  movements.  This  is  done  to  increase 
pressure  on  the  players  and  influence  their  command  and 
control  (C2 )  decision  making  cycle.  This  task  is  easily 
accomplished  by  assigning  these  units  missions  which  move 
them  closer  to  where  blue  forces  might  be  located  for  a  few 
minutes  and  then  moving  them  away  again.  Similar  procedures 
can  be  used  to  automate  enemy  and  neutral  sea  and  air  units. 
In  the  scenario.  Red  forces  also  deploy  both  land  and  sea 
mines.  These  minefields  are  created  using  the  CE->CONSTRUCT 
menu  command.  Appendix  A  provides  batch  file  listings  for 
all  the  red  forces  implemented  so  far. 

C.  PARAMETRIC  DATABASE 

The  Parametric  Database  is  the  portion  of  MTWS  that 
stores  all  information  regarding  unit,  vehicle,  and  weapon 
characteristics.  This  database  is  highly  modifiable,  and 
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many  traits  of  current  systems  and  units  can  be  varied  to 
represent  new  or  different  capabilities.  This  is  useful  for 
the  A2C2  experiment.  Although  the  experiment  is  designed  to 
simulate  a  real  world  amphibious  assault,  the  A2C2  scenario 
would  require  too  much  time  and  be  too  complex  for  the 
experiment  itself.  Additionally,  blue  forces  in  the 
experiment  have  been  purposely  designed  to  be  stronger  than 
the  corresponding  red  forces.  Early  loss  of  key  units  in 
this  simulation  would  effectively  change  the  architecture 
being  tested,  and  therefore  would  skew  the  data.  Minefields 
and  bridges  have  also  been  modified  in  the  parametric 
database.  Once  they  have  been  detected,  they  can  be  removed 
in  a  time  efficient  manner. 

D .  OTHER  SETTINGS 

1.  Clock 

The  simulation  has  been  configured  to  operate  optimally 
at  a  time  compression  factor  of  1:1.  This  is  the  default 
setting  in  MTWS,  but  the  option  can  be  changed  in  the  MTWS 
Station  Control  window  under  the  EXERCISE  CONTROL- >RATE  menu 
option  to  play  at  a  faster  rate,  if  desired. 

2 .  Mode/State 

When  the  simulation  is  loaded,  the  default  state  is  in 
the  ADMIN  mode.  To  start  the  system  clock  running,  this 
mode  should  be  changed  to  RUN,  through  the  EXERCISE  CONTROL- 
>OPERATION- >STATE  menu  option  in  the  MTWS  Station  Control 
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window.  Additionally,  the  EXERCISE  CONTROL- >OPERAT I ON ->MODE 
menu  option  should  be  set  to  RESUME  if  it  is  currently  in 
SUSPEND  mode. 
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III.  PRE- START  STATION  CONFIGURATION 


Each  MDS  station  in  MTWS  needs  to  be  configured  for  the 
appropriate  user.  Before  the  MDS  stations  can  be 
configured,  the  scenario  must  be  loaded  as  described  in 
Chapter  II.  Due  to  constraints  in  MTWS,  station  settings 
have  to  be  reconfigured  each  time  a  new  exercise  is  loaded. 


Command  Entry 


Map  Window 


Spot  Reports 


— 

Status  Window 

Icon 

Icon 

Icon 

Icon 

Figure  12 .  Recommended  MTWS  Windows  Layout . 
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A.  WINDOWS  LAYOUT 

There  are  four  windows  that  are  essential  to  playing 
the  scenario  in  MTWS.  The  command  entry  window,  the  map 
window,  the  spot  report  window,  and  the  status  window. 
Prior  to  the  start  of  the  scenario,  these  windows  need  to  be 
sized  and  positioned  so  that  they  are  always  available  to 
the  player.  Each  window  contains  vital  information  or 
functionality  that  must  be  easily  available  to  the  player  at 
all  times.  Figure  12  shows  the  recommended  windows  layout 
for  an  MDS  station. 

B.  MAP  WINDOW  SETTINGS 

The  Display  Categories  menu  item  is  used  to  turn 
certain  items  and  units  in  MTWS  on  and  off.  This  menu  only 
contains  two  options:  Display  Objects,  and  Display 
Environment.  This  field  should  not  be  manipulated  by  the 
players.  The  Display  Objects  option  brings  up  a  window  that 
allows  users  to  vary  the  types  of  objects  displayed  on  the 
map.  The  only  option  in  this  window  that  needs  to  be 
changed  from  the  default  settings  is  under  the  water 
category  on  the  button  labeled  Objects.  The  user  should 
select  the  Objects  button  under  this  option.  Another  window 
will  open  that  lists  several  features.  To  make  the  display 
less  cluttered,  the  Beach  Geometries  feature  should  be 
turned  off. 
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Under  the  Display  Environment  menu  option,  a  window  is 
displayed  that  allows  the  user  to  control  which  players  or 
forces  are  displayed  on  the  map  window.  There  are  options 
available  for  controlled  objects  (units,  ships,  aircraft, 
etc.)  and  uncontrolled  objects  (minefields  and  other 
obstacles.)  In  both  cases,  the  red  forces  (AG)  and  civilian 
forces  (CIV)  should  be  deselected,  so  they  are  not  displayed 
on  the  map.  These  objects  will  only  appear  on  the  map 
windows  if  they  are  detected  by  blue  forces.  No  other 
options  in  this  window  should  be  modified. 


Map  Options  Display  Options  Display  Categories 


Locate 
Identify 
Calculator 
Range  Fan 
Update  Times 
Small  Font 
Large  Font 
Clear  Locations 
Restore  Map  Colors 


Figure  13.  Display  Options  Menu. 


C.  CONTROLLER  ASSIGNMENTS 

Controller  assignments  are  made  through  the  System 
Operations  window  which  appears  as  an  icon  when  an  MDS 
station  is  first  launched.  Double  clicking  this  icon  will 
display  the  window.  In  the  A2C2  scenario,  each  station  used 
in  the  experiment  should  only  have  one  controller  selected. 
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To  select  a  controller,  the  EXERCISE  CONTROL  menu  option  is 
selected,  and  the  ASSIGN/DEASSIGN  option  is  chosen.  A 
window  will  open  with  all  the  possible  controllers.  If  a 
certain  station  is  to  be  used  for  Player  0,  then  MANCON_l 
should  be  the  selected  controller.  If  the  station  is  for 
Player  1,  the  MANCON_2  should  be  selected,  and  so  on.  These 
controller  assignment  determine  who  controls  units  and  which 
messages  will  appear  in  the  Spot  Report  windows.  It  is 
important  that  a  player  is  assigned  only  the  necessary 
controllers  so  they  are  not  overwhelmed  by  message  traffic 
that  doesn't  pertain  the  their  units. 

The  computer  that  is  configured  as  the  MSC  should  have 
all  the  controllers  assigned  to  it.  This  will  allow  the  MSC 
to  capture  all  the  spot  reports  that  are  generated  during 
the  scenario  and  log  them  in  a  file.  This  is  useful  for 
data  extraction  as  discussed  in  Chapter  IV. 

D.  STATION  CONTROL  WINDOW 

On  each  MDS  station,  there  is  an  icon  at  the  bottom  of 
the  display  called  MTWS  Station  Control.  When  this  icon  is 
double  clicked,  it  opens  up  the  Station  Control  window.  In 
order  for  an  MDS  station  to  be  included  in  a  scenario,  the 
status  should  be  changed  from  Off  Line  to  On  Line.  This 
will  register  the  MDS  station  on  the  MTWS  network.  The 
privileges  a  user  has  over  MTWS  is  determined  by  the  User 
Privilege  Level  setting.  The  lowest  setting,  zero,  only 
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allows  the  user  to  use  the  functions  that  are  necessary  for 
gameplay.  When  the  privilege  level  is  zero,  users  can  not 
instantaneously  move  objects  or  units,  and  they  cannot 
change  the  map  display  settings,  or  change  controller 
assignment.  Level  two  is  the  highest  privilege  setting  and 
requires  a  password  to  be  accessed.  When  an  MDS  station  is 
being  configured,  and  controllers  are  being  assigned,  the 
privilege  level  must  be  set  to  two.  Before  the  scenario  is 
started  however,  the  level  must  be  returned  to  zero.  Level 
one  is  an  intermediate  level  that  allows  an  MTWS  controller 
to  have  access  to  certain  advanced  functions,  but  not 
complete  control  of  the  scenario.  Level  one  is  not 
necessary  for  the  A2C2  scenario. 
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IV.  PLAYING  THE  SIMULATION 


This  chapter  is  divided  into  two  primary  sections .  The 
first  section  describes  actions  and  commands  that  will  be 
performed  by  the  players.  The  second  section  describes  the 
settings  and  parameters  that  need  to  be  modified  prior  to 
the  start  of  the  scenario  by  the  personnel  responsible  for 
administering  the  experiment. 

MTWS  is  a  complex  simulation  that  was  originally 
intended  for  well-trained  and  knowledgeable  users.  Since 
participants  of  the  A2C2  experiment  typically  have  only 
limited  experience  using  MTWS,  it  is  useful  to  provide  an 
outline  of  the  key  features  and  commands  they  will  need  to 
know  in  order  to  play  the  simulation.  This  chapter  provides 
an  overview  of  commands  and  instructions  the  players  need  to 
know . 


A.  FREQUENTLY  USED  COMMANDS 

The  MTWS  commands  used  most  frequently  by  the  players 
for  this  simulation  are  instructions  for  ground  unit 
operations  and  air  operations.  In  the  Command  Entry  window 
there  is  a  menu  option  called  COMMANDS.  This  menu  item, 
when  selected  with  the  mouse,  appears  as  shown  in  Figure  14. 
Since  there  are  dozens  of  submenus,  the  items  important  to 
the  A2C2  simulation  will  be  highlighted  in  the  following 
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sections.  The  only  commands  shown  here  are  the  ones  that 
are  important  to  the  actual  players  during  gameplay  and  do 
not  include  commands  that  are  used  for  the  creation  of  the 
scenario. 


C<j>MMAND 


REPORTS 


AIR 

> 

FIRE  SUPPORT 

> 

GROUND 

> 

INTELLIGENCE 

> 

CE 

> 

CSS 

> 

ENVIRONMENT 

> 

NBC 

> 

SHIP  OPS 

> 

Figure  14.  Command  Menu  Options. 

1 .  Air 

AIR->MISSION->DIVERT  allows  the  player  to  update  an  air 
mission  that  is  already  launched.  This  command  requires  the 
user  to  input  an  existing,  and  airborne,  air  mission  name, 
as  well  as  one  or  more  locations.  Each  point  is  accompanied 
by  settings  for  mission  type  (attack,  waypoint,  land,  orbit 
etc.)  and  altitude  (very  low,  low,  medium,  high).  The  user 
should  specify  the  flight  profile,  and  for  this  experiment, 
they  must  specify  the  last  point  as  an  orbit.  This  prevents 
the  air  mission  from  performing  a  Return  to  Base  (RTB) 
automatically.  If  an  air  mission  RTBs,  it  will  be  more  than 
ten  minutes  of  actual  time  before  the  simulation  allows  the 
aircraft  to  be  launched  again.  Players  should  not  use  this 
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command  to  create  and  launch  their  own  air  missions. 
Instead  they  should  use  the  batch  files  that  perform  this 
function. 

2.  STS  (Ship  to  Shore) 

This  command  is  not  needed  by  the  players.  All  ship  to 
shore  operations  are  performed  through  batch  files. 

3 .  Fire  Support 

FIRE  SUPPORT- >DEFINE  QUICK  MISSION  is  used  to  provide 
naval  gunfire.  The  quick  fire  support  mission  is  the  most 
useful  for  this  scenario.  It  requires  only  target  location 
information,  or  the  target's  name,  the  name  of  the  firing 
ship,  and  the  ammunition  to  be  used.  The  players  should 
have  a  list  of  available  ammunition  from  each  ship  prior  to 
the  start  of  the  exercise. 

4 .  Ground 

GROUND- >UNIT->MISSION  specifies  actual  unit  and  troop 
movements  on  the  ground.  The  more  important  subcommands 
included  in  this  command  include  the  functions  to  MOVE, 
ATTACK,  and  DEFEND.  There  are  options  in  this  menu  to 
control  speed  and  to  override  to  the  default  speed  and 
movement  settings  for  certain  terrain.  Both  speed  and 
movement  override  should  be  selected,  and  a  desired  speed 
manually  entered.  The  players  should  enter  a  reasonable 
speed  of  3  0  to  40  kilometers  per  hour  (kph)  .  Like  an  air 
mission,  a  unit  mission  can  involve  multiple  movements  and 
functions. 
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5 .  Intelligence 

This  command  is  not  used  by  the  players . 

6.  CE 

CE->REMOVE  is  the  only  command  under  this  menu  that  the 
players  will  use.  Only  a  player  controlling  an  engineering 
unit  can  use  this  function.  In  this  scenario,  CE->REMOVE 
will  be  used  to  remove  minefields  and  bridges. 

7.  CSS 

This  command  is  not  used  by  the  players . 

8 .  Environment 

This  command  is  not  used  by  the  players . 

9.  NBC 

This  command  is  not  used  by  the  players . 

B.  MAP  WINDOW  FUNCTIONS 

The  map  window  provides  the  primary  interface  from  MTWS 
to  the  user.  The  menu  item  labeled  Map  Options  is  used  to 
manipulate  the  position  and  zoom  level  of  the  map.  The  map 
display  in  MTWS  is  capable  of  displaying  any  level  of  detail 
from  the  world  view  down  to  a  detailed  level .  A  player  can 
customize  map  settings  so  that  the  map  encompasses  only  the 
units  they  are  concerned  with.  The  primary  functions  under 
this  menu,  to  be  used  by  the  player,  are  the  pan,  zoom,  and 
previous  map  options.  The  Map  Manager  feature  located  under 
this  menu  item  allows  the  user  to  select  a  map  background 
from  a  list  of  various  digitized  navigational  maps,  but  this 
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feature  is  not  used  for  this  scenario.  Any  of  these  options 
will  be  available  to  players,  but  the  most  useful  ones  will 
be  Identify,  and  Clear  Locations.  Identify  allows  the  user 
to  select  an  area  of  the  screen  containing  red  or  blue 
units,  and  it  will  return  information  about  these  units,  if 
the  information  is  available.  Information  includes  precise 
location,  unit  name,  and  unit  type.  This  is  most  useful  if 
players  want  to  launch  precision  attacks  through  airborne  or 
naval  fire  missions.  The  Clear  Locations  option  cleans 
markers  off  the  screen.  Markers  are  created  anytime  a 
player  clicks  the  mouse  on  the  map  area.  After  a  period  of 
time,  these  marks  can  significantly  clutter  the  map  display. 

C .  SPOT  REPORTS 

The  Spot  Reports  window  contains  textual  message 
traffic  that  pertains  to  the  units  assigned  to  the  active 
controllers.  Section  B  describes  how  to  assign  the  active 
controllers  to  players  and  units.  Information  in  the  spot 
report  windows  is  very  useful  because  it  is  generally 
updated  faster  than  the  map  window.  Spot  reports  include 
pertinent  information  about  a  unit,  such  as  anemy  target 
sightings,  status  of  a  unit's  mission,  when  a  unit  attacks 
or  is  attacked,  as  well  as  damage  assessment  to  that  unit. 
A  player  will  only  see  spot  reports  pertaining  to  units 
under  their  control. 
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V.  EXTRACTING  DATA  FROM  MTWS 

This  chapter  will  describe  how  MTWS  collects  data  and 
highlight  some  of  the  possible  methods  for  extracting 
exercise  data  from  MTWS.  There  will  be  no  discussion  of 
methods  used  to  analyze  these  data. 

A.  LOG  FILES 

When  a  scenario  is  loaded  and  running,  MTWS  maintains 
logs  of  for  all  commands  that  were  successfully  executed, 
and  a  log  of  all  reports  that  are  generated  in  the  Spot 
Reports  window  are  saved  into  a  file.  The  files  are 
automatically  over-written  each  time  MTWS  is  restarted. 
After  completing  each  trial,  these  files  need  to  be  saved  to 
a  new  location  to  prevent  loss  of  data.  These  files  are 
simple  text  files  that  can  be  used  to  evaluate  which  tasks 
were  performed  when,  and  how  successfully  they  were 
executed.  [Ref.  3]  . 

1.  Command  History 

The  "command. history"  file  is  located  in  the  directory 
/mtws/db/man/  [exercise  name]  .  In  the  case  of  this 
experiment-,  it  would  be  in  the  /mtws/db/man/A2C2  directory. 
This  file  contains  a  complete  list  of  all  the  commands  that 
were  executed  from  the  Command  Entry  window  for  that 
particular  station.  This  file  includes  all  the  commands 
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that  were  executed  when  the  batch  files  were  invoked  at  the 
start  of  the  scenario.  The  data  in  the  "command. history" 
files  are  similar  to  the  data  that  would  appear  in  a  batch 
file.  Additionally,  these  data  include  the  MDS  station 
number  of  the  player  that  executed  the  command,  and  the  hour 
and  minute  (scenario  time)  that  the  command  was  executed. 
Figure  15  contains  a  few  sample  lines  from  a 
"command. history"  file. 


241913ZFEB98;mds005;UNIT;MISSION;P5_SOF;MOVE;VEE; ;MV_PLANS; YES; 30 /OVERRIDE; ;  {0 
352SEQ209088; ; 52SEQ214083; ;52SEQ206076; ; }$ 

241913ZFEB98;mds005;UNIT;MISSION;P5_ENG;MOVE;VEE; ;MV_PLANS;YES;30;OVERRIDE; ;  {0 
352SEQ206076; ;52SEQ205076; ;52SEQ205076; ; } $ 

241914ZFEB98;mds005;UNIT;MISSION;P3_ENG;MOVE;VEE; ; MV  PLANS ; YES ; 3 0 ; OVERRIDE ; ; {0 
152SEQ228100; ; } $ 

241915ZFEB98;mds005;AIR_MISSION;DIVERT;Pl_CASl; {0252SEQ283120;MEDIUM;WAY_POINT 
;S2SEQ245056;MEDIUM;ORBIT; }/$ 

241916ZFEB98;mdsOOS;UNIT;MISSION;P3_INF2;MOVE;VEE; ;MV_PLANS;YES;30;NO  OVERRIDE 
; ; { 0152SEQ229025 ; ; } $ 

241916ZFEB98;inds005;UNIT;MISSION;P3_INF3;MOVE;VEE; ;MV  PLANS; YES; 30;NO  OVERRIDE 
; ; {0152SEQ229025; ; }$ 

24 1916ZFEB98;mds005;UNIT /MISSION; P3_INFl;MOVE;VEE; ;MV_PLANS;YES;30;NO  OVERRIDE 
; ; { 0152SEQ229025 ; ; } $ 

2 4 1918ZFEB98;mds005 /UNIT /MISSION; P3_INF1;M0VE;VEE; ;MV_PLANS;YES;30/NO  OVERRIDE 
;; {0152SEQ223019; ; }$ 

241919ZFEB98;mds005 /UNIT/MISSION; P3_INF1; ATTACK; VEE;/MV_PLANS; YES ;30; OVERRIDE; 

; {0152SEQ222020; ; } $ 

241919ZFEB98;mds005;UNIT;MISSION;P3_INF2;ATTACK;VEE;;MV  PLANS; YES; 30 /OVERRIDE; 

; {0152SEQ222020; ; ) $ 

241919ZFEB98 ;mds005;UNIT;MISSION;P3_INF3; ATTACK; VEE; ;MV_PLANS; YES; 30 ; OVERRIDE; 

; {0152SEQ222020; ; } $ 

241920ZFEB98;mds005;AIR_MISSION;DIVERT;Pl_CASl; {0252SEQ223019;VERY_LOW; ATTACK; 
52SEQ238 030 /MEDIUM; ORBIT; } TROOPS;  $ _ 

Figure  15.  Sample  data  from  "command. history"  file. 


One  possible  method  of  extracting  data  from  this  file 
would  be  to  import  the  text  file  into  a  spreadsheet  program 
such  as  Microsoft  Excel .  Excel  allows  a  user  to  parse  data 
into  separate  cells  so  it  can  be  managed  more  easily,  or 
sorted  according  to  the  analyst's  preference.  By  studying 
this  reorganized  file,  it  is  easy  to  determine  if 
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coordinated  attacks  were  executed  properly.  Similarly,  the 
lines  of  text  could  be  treated  as  database  records  and 
imported  into  a  database  program  such  as  Microsoft  Access 
for  further  data  reduction  and  analysis. 

The  "command. history"  file  collects  commands  from  all 
MDS  stations  that  are  on  the  network  into  one  composite 
file.  .  This  file  can  be  extracted  from  any  MDS. 

2 .  Spot  Report  Log 

The  other  file  that  is  useful  to  the  data  analysis  is 
the  spot  report  log.  It  is  also  specific  to. the  MDS.  This 
file  is  located  in  the  /tmp  directory  and  is  called 
"Spot_Report_Log" .  This  file  is  a  useful  complement  to  the 
command  history  file.  It  contains  every  spot  report  that 
was  generated  on  all  the  MDS  stations.  Like  the  command 
history  file,  this  data  also  includes  the  time  each  spot 
report  occurred,  and  which  units  were  involved.  Certain 
spot  reports  are  useful  because  they  quantify  the  casualties 
and  damage  inflicted  on  units  during  the  simulated  combat. 
The  spot  reports  can  be  correlated  to  the  commands  in  the 
"command. history"  file,  and  the  overall  effectiveness  of  a 
particular  task  can  be  assessed  in  this  manner.  Figure  17 
shows  sample  output  from  a  spot  report  log  file.  The  spot 
reports  shown  here  correspond  to  the  commands  shown  in 
Figure  15  and  Figure  16 . 
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X  Microsoft  Excel  -  command  history  txt 


io.i»a:aQty; 


*m  ik-i%+  *  nit at « « s  ioo*,/®: 

TwjnTTilKin^ri  *7 Wa" W&f 7> ' '» -X- i 

. .  . ? . . 


174  24191 1ZFEB98  MSCDBM  jMODE  RESUME  $ 

175  24 1911ZFEB98  mdsOO 5  ]AIR_Missi6  DEFINE  ;LPD_LAND_P3jMV-22  i  P2  LPD1  P2  LPt 

176  24i9i'{zFEB98'nrids0C5 . 1  SERIAL . '  DEFINE . ;LPD~IANd"p3~LF . P2T=Di"  Usl  .OF  7{6lP3 

ITT  24191 12FEBW  ;  mdsOOS . | SERIAL  /ASSOCIATE iLPcTLANDJ=^LPD_ljWD^PFil^1  $  . “ . ” 


$78-24191 1ZFEB98 

mdsOOS 

;A!R_MIS$IO  DEFINE 

1  LPD_LAND_P3_  M  V-22 

1  P2  LPD1  P2  LPC 

l?9  24191 1ZFEB98 

mdsOOS 

!  SERIAL 

DEFINE 

!LPD  LAND  P3  LF 

P2  LPD1  USE  OF  /{01P3 

ill  24191 1ZFEB98 

mdsOOS 

:  SERIAL 

1  ASSOCIATE 

;LPD_LAND_P3  LPD  LAND  P3  INF2  $ 

i 

il6l  24191 2ZFEB98 

mds005 

;air_missio  define 

!LPD  LAND  P3  MV-22 

1  P2  LPD1  P2  LP[ 

:182:241912ZFEB98 

mds005 

:  SERIAL 

DEFINE 

:LPD  LAND  P3  LF 

P2  LPD1  USE  OF  ,{01P3 

183  241912ZFEB98 

mds005 

1  SERIAL 

ASSOCIATE 

!LPD  LAND  P3  LPD  LAND  P3  INF3  $ 

1S4;241912ZFEB98 

mds005 

lAIR  MISSIO  DEFINE 

IP1_CAS1 

:  FA-18 

2  P' 

CV1  /PI  cv 

1-85  241912ZFEB98 

mds005 

jAIR^MISSIO  DEFINE 

IP3JCAS1 

FA-18 

2  PJ 

CV1  /PI  cv 

24 1 91 2ZFEB98 

mds005 

;air_missiodefine 

iP4  CAS1 

FA-18 

2  P 

CV1  /PI  cv 

IH/j  24191 3ZFEB98 

mdsOOS 

jUNIT 

MISSION 

IP5_S0F 

MOVE 

VEE 

;MV  PL 

llli  24 191 32FEB98 

mdsOOS 

j  UNIT 

MISSION 

I  P5_ENG 

MOVE 

•  VEE 

IMV  PL 

189 1 24 1 914ZFEB98 

i  mds005 

IUNIT 

!  MISSION 

i  P3_ENG 

MOVE 

VEE 

iMV  PL 

IMS  24191 5ZFEB98 

:  mdsOOS 

iAIR.MISSIO  DIVERT 

IPIJCASI 

{0252SEQ283120  MEDIUM  WAY  POI  52SEQI 

|91;2419162FEB98 

i  mds005 

IUNIT 

MISSION 

IP3JNF2 

MOVE 

VEE 

:MV  PL 

192  24 191 62FEB98 

l  mdsOOS 

IUNIT 

MISSION 

jP3_INF3 

MOVE 

VEE 

IMV  PL 

193  241916ZFEB98 

mds005 

;UNIT 

MISSION 

:P3JNF1 

MOVE 

IVEE 

MV  PL 

S  2419182FEB98 

mdsOOS 

IUNIT 

MISSION 

IP3JNF1 

MOVE 

VEE 

:MV„PL 

241919ZFEB98  imds005 j UNIT  MISSION  IP3JNF1  ATTACK  VEE 

241919ZFEB98  TrndsOOS . iUN'T . .MISSION . |P3JNF2 . ^ATTACK . [vee 


|g7j241919ZFEB98  mds005 
198  241920ZFEB98  mdsOC5 

.  conwrusncthi  *lory  /  a™. 


IUNIT  MISSION 

I  AIR  MISSIO  DIVERT 


iP3_INF3 
:P1  CAS1 


ATTACK  VEE  MV_PL/ 

/attack . Ivee  | . imvjplI 

ATTACK' .  VEE  . MvfPL 

{0252SEO223019  VERY_LO’ ATTACK  52SEO« 


Figure  16.  Command  History  data  imported  into  Excel. 


In  addition  to  the  data  that  is  collected  by  the 
computer,  audio  and  video  recordings  are  routinely  made  of 
each  A2C2  trial.  Additionally,  A2C2  analysts  also  monitor 
the  progress  of  the  trial  in  real  time. 

The  "Spot_Report_Log"  is  station  specific.  As 
mentioned  in  Chapter  III,  all  the  controllers  on  the  MSC 
should  be  activated.  This  allows  the  "Spot_Report_Log"  file 
on  the  MSC  to  contain  all  the  spot  reports  that  were 
generated  for  the  entire  scenario.  This  prevents  the  time 
consuming  process  of  consolidating  separate  files. 
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ENGAGEMENT  STATUS  CHANGE  ; P3_INF2 ; 52SEQ224022 ; 241920ZFEB98 ;MANC0N_4 ;HAS 
INITIATED  ENGAGEMENT  WITH  SB_DEFENSE 
PRINTED  BY:  mds005 

ENGAGEMENT  STATUS  CHANGE  ;P3_INF3;52SEQ224022;241920ZFEB98;MANCON_4;HAS 
INITIATED  ENGAGEMENT  WITH  SB_DEFENSE 
PRINTED  BY:  mds005 

STATUS  CHANGE ; SB_DEFENSE ; 52SEQ223 02  0 ; 241920ZFEB98 ; AGCON_l ;  RECEIVING 
AIR-TO-SURFACE  FIRE 
PRINTED  BY:  mdsOOS 

UNIT  SB_DEFENSE;  P1_CAS1; TROOPS  1  WIA, 

PRINTED  BY:  mds005 

AS  SES  SMENT  REPORT ; P5_ENG 

AIR_TO_SURFACE ; 52SEQ2 06076 ; 241920ZFEB98 ;MANCON_6 ; 

UNIT  SB_DEFENSE ;  P1_CAS1 ; TROOPS  1  WIA, 

PRINTED  BY:  mds005 

ENGAGEMENT  STATUS  CHANGE ; SB_DEFENSE ; 52SEQ22302 0 ; 241921ZFEB98 ; AGCON_l ; IS 
ENGAGED  BY  P3_INF1 
PRINTED  BY:  mds005 

ENGAGEMENT  STATUS  CHANGE ; SB_DEFENSE ; 52SEQ22302 0 ; 241921ZFEB98 ; AGCON_l ; IS 
ENGAGED  BY  P3_INF2 
PRINTED  BY:  mds005 

ENGAGEMENT  STATUS  CHANGE ; SB_DEFENSE ; 52SEQ223020 ; 241921ZFEB98 ; AGCON_l ; IS 
ENGAGED  BY  P3_INF3 
PRINTED  BY:  mds005 

UNIT  CASUALTY  LIMIT  ; SB_DEFENSE; 52SEQ223020 ; 241921ZFEB98 ;AGCON_l ;HAS 
REACHED  EFFECTIVE  CASUALTY  LIMIT 
PRINTED  BY:  mds005 

REPORT;  GROUND_ENGAGEMENT  1; 52SEQ224021;241921ZFEB98 ; AGCON_l , MANCON_4 ; 

UNIT  SB_DEFENSE ;  TROOPS  4  WIA,  3  KIA 
PRINTED  BY:  mds005 

Figure  17.  Sample  data  in  spot  report  log. 

B.  FUTURE  CAPABILITY 

The  MTWS  Analysis  and  Review  System  (MARS)  is  an 
augmentation  to  MTWS  that  is  currently  under  development. 
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The  goal  of  the  MARS  system  is  to  provide  real  time  analysis 
of  an  exercise  as  well  as  an  after-action  review  capability. 
MARS  will  require  two  additional  MDS  stations  to  run.  [Ref. 
2]  . 
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VI .  EVALUATION 


The  goal  of  this  chapter  is  to  provide  an  evaluation  of 
the  MTWS  scenario  in  two  ways.  The  first  half  of  the 
chapter  will  discuss  limitations  and  concerns  that  are 
unique  to  MTWS.  The  second  half  will  compare  current 
capabilities  of  the  MTWS  version  of  the  scenario  to  those 
of  the  DDD  version. 

A.  MTWS  ISSUES 

In  many  ways,  MTWS  is  much  less  rigidly  structured  than 
DDD.  MTWS  does  not  force  the  order  of  events  by  requiring 
prerequisite  tasks  to  be  accomplished  before  players  are 
allowed  to  continue.  In  addition,  MTWS  is  stochastic  in 
nature,  so  even  though  the  specific  probabilities  of  events 
occurring  can  be  assigned  in  the  parametric  database,  the 
outcome  of  any  given  event  is  a  random  variable.  Several 
additional  key  issues  have  been  identified  that  are 
significantly  different  between  MTWS  and  DDD. 

1.  Identification 

In  DDD,  air  and  sea  tracks  appear  on  the  display  as  a 
question  mark  until  they  have  been  identified.  A  track  can 
be  identified  by  moving  a  friendly  unit  into  detection 
range,  and  using  the  IDENTIFY  option.  MTWS  does  not  allow 
such  a  clear  cut  process  for  identification.  Most  units 
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have  sensors  or  communications  with  other  units  that  can 

accomplish  this,  but  unlike  the  configuration  of  DDD  III 
used  in  the  A2C2  scenario,  the  initial  detection  range  units 
in  MTWS  does  not  cover  the  entire  area  of  operations 
displayed  on  the  computer  screen.  Because  of  this,  an 

unknown  track  will  not  appear  on  the  display  until  it  has 

been  detected.  Once  detected,  it  appears  as  a  purple 


rectangle 

on  the  display. 

Even 

though  a  unit 

may 

be 

detected, 

only  some 

or  all 

of 

the  information 

may 

be 

available, 

including 

size, 

type. 

and  alliance 

of 

the 

detected  unit.  The  spot  reports  displayed  in  the  spot 
report  window  will  often  contain  more  information  than  is 
available  on  the  map  display.  This  process  makes  target 
detection  and  identification  a  much  more  complex  process  in 
MTWS. 

The  location  of  the  enemy,  in  many  cases,  is  known 
prior  to  the  start  of  the  scenario,  so  there  is  no 
difficulty  in  identification.  The  original  DDD  scenario 
uses  of  several  "random"  tracks  that  "pop  up"  and  move 
around  the  screen.  Identifying  these  tracks  in  DDD  is  a 
relatively  simple  process  for  the  operator.  The  random 
track  aspect  of  the  MTWS  scenario  has  not  yet  been 
implemented.  If  the  same  number  of  random  tracks  were  used 
in  MTWS,  the  task  of  detecting  and  identifying  them  would  be 
more  difficult  and  time  consuming  than  DDD.  When  this 
feature  is  implemented  in  MTWS  it  should  probably  use  a  more 
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modest  number  of  tracks  than  DDD  in  order  to  keep  the 
scenario  playable.  Another  alternative  would  be  to  modify 
the  parametric  database  to  increase  the  detection  ranges  of 
various  units  or  to  configure  MTWS  to  simulate  a  UAV  to 
increase  the  probability  of  detection  of  enemy  targets. 

2 .  Combat 

In  DDD,  if  some  or  all  of  the  criteria  were  met  to 
conduct  an  assault  on  the  enemy,  the  enemy  unit  would 
automatically  be  destroyed.  However,  if  the  attackers  did 
not  have  adequate  resources  or  properly  time  the  attack, 
they  would  receive  a  lower  score  for  the  task.  If  the 
attacking  units  did  not  have  any  of  the  necessary  resources, 
the  computer  would  not  allow  the  attack.  In  DDD  friendly 
units  can  not  be  defeated,  but  the  players  are  penalized  in 
scoring  their  efficiency  instead. 

In  MTWS,  unit  composition  and  assets  can  be  varied 
greatly.  Blue  forces  can  be  configured  to  be  substantially 
stronger  or  weaker  than  Red  forces,  but  MTWS  will  not 
prevent  any  attacks  the  way  DDD  will.  The  effectiveness  of 
the  attack  will  be  limited  by  the  types  of  units  used  and 
the  assets  these  units  contain.  Because  combat  in  MTWS  is  a 
weighted,  but  stochastic  process,  the  outcome  of  any 
conflict  can  not  be  absolutely  pre- determined. 
Approximations  were  made  in  determining  relative  unit 
strengths  for  the  MTWS  scenario,  but,  with  time  and 
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research,  a  more  reliable  and  predictable  balance  of 
strengths  between  Red  and  Blue  forces  could  be  determined. 


B.  DDD  VS  MTWS 


There  are  several  issues  specific  to  the  A2C2  scenario 
important  to  evaluating  the  performance  of  architectures. 
These  issues,  or  factors  that  directly  affect  them  have  been 
compiled  and  listed  in  tabular  format  in  this  section.  The 
issues  have  been  divided  into  two  sections. 

The  first  section  is  a  listing  of  the  specific  tasks 
within  the  scenario  that  have  to  be  completed  by  the 
participants  of  the  A2C2  experiment.  This  section  compares 
and  contrasts  any  significant  differences  between  MTWS  and 
DDD  that  might  affect  or  impact  the  gameplay  of  the 
scenario . 

The  second  section  is  capabilities,  and  these  more 
general  aspects  of  the  A2C2  scenario  or  tasks  that  are  could 
be  completed  at  any  time  such  as  clearing  sea  mines.  Issues 
that  are  more  complicated  or  significantly  different  from 
the  DDD  implementation  of  the  A2C2  experiment  are  discussed 
in  this  section. 

1 .  Tasks 


Task:  Releasing  Assets 


Requirements:  A  player's  assets  are  not  necessarily 
initially  under  that  player's  control.  An  asset  may  be 
located  on  another  asset,  such  as  a  ship  which  is  controlled 
by  a  second  player.  The  owner  of  the  asset  needs  to  request 

that  second  player  release,  or  launch  their  asset. _ 

DDD  I  MTWS 
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ine  dud  sortware  requires  a 
player  to  request  that  the 
second  player  release  their 
asset.  This  request  is 
mandatory  in  the  software, 
and  is  usually  followed  by  a 
verbal  request  as  well.  The 
second  player  must  release 
the  asset  using  a  menu  option 
in  the  DDD  software .  The 
second  player  is  not  able  to 
release  the  asset  unless  the 
first  player  initiated  the 
request  through  the  DDD 
software . 


MTWS  does  not  force  this 
process  as  does  DDD.  The 
launching  or  releasing  assets 
could  by  done  by  anyone,  but 
the  procedure  forced  by  DDD 
should  be  followed,  except 
that  all  requests  and 
acknowledgements  are  only 
verbal .  Since  these 
functions  are  performed  by 
batch  files  in  MTWS,  the 
process  could  be  enforced  by 
only  making  batch  file  names 
available  to  the  player  who 
is  allowed  to  release  the 
assets . 


Task:  Landing  Amphibious  Forces 

Requirements:  Players  are  required  to  release  forces  from 
various  sea  assets  and  transport  them  to  the  North  or  South 
Beaches  using  MV22s  (airborne)  and  AAAVs  (seaborne) . 

DDD 

MTWS 

A  first  player  will  release  a 
second  players  MV22  or  AAAV 
using  the  technique  mentioned 
"Releasing  Assets"  section 
above.  Once  these  units  have 
landed  at  one  of  the  desired 
locations,  the  second  player 
will  use  a  menu  option  to 
unload  the  units. 

Setting  up  either  an  airlift 
mission  or  a  sea  transport  is 
more  complicated  in  MTWS. 

Batch  files  were  used  to 
automate  the  process  of 
airlifting  units  to  the  North 
and  South  beaches .  Since 
batch  files  would  have  been 
used  for  sealift  as  well,  the 
processes  of  sealift  and 
airlift  would  have  been 
indistinguishable  to  the 
players.  In  the  current 
implementation  of  the  A2C2 
scenario,  airlift  (MV22s)  are 
used  for  deploying  all  units 
to  the  beaches. 

Task:  Taking  the  Beaches 

Requirements:  Several  players  are  required  to  launch  a 

coordinated  attack  on  both  the  North  and  South  beaches  at 
the  same  time. 

DDD 

MTWS 

Each  player  selects  the 

ATTACK  option,  and  selects 
the  desired  target,  and  a 

Similar  to  DDD,  each  player 
can  issue  the  commands  to 
launch  an  attack,  but  not 
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confirmation  dialog  box  will 
appear.  Once  all  the  players 
involved  in  the  coordinated 
attack  have  accomplished 
this,  .they  will  all  launch 
their  attacks  simultaneously. 
If  the  coordinated  attack  did 
not  employ  all  required 
platforms,  or  did  not  time 
their  attack  properly,  points 
will  be  deducted. 


confirm  the  attack  until 
everyone  is  ready.  Assuming 
the  Blue  forces  appropriately 
out -mass  the  Red  forces,  the 
Red  forces  will  be  destroyed. 
If  red  forces  are  not 
destroyed,  follow  on  attacks 
may  be  required.  If  more 
attacks  are  required  (if  too 
few  or  inappropriate  assets 
have  been  used)  then  Blue 
forces  will  suffer  more 
casualties.  This  information 
will  be  logged  in  the  log 
files  generated  during  the 
trial.  It  is  up  to  the 
analysts  to  determine  a 
method  measuring  the  success 
of  the  attack.  While  the 
Blue  forces  have  been 
configured  to  be 
significantly  stronger  than 
the  Red  Forces,  the 
capabilities  of  both  sides 
will  need  to  be  more 
accurately  configured  than 
they  are  in  the  current 
implementation.  See  Chapter 
VII  for  a  more  detailed 
summary  of  this  issue. 


Task:  Removing  the  Bridge 

Requirements:  Blue  forces  are  required  to  determine  which 

one  of  two  bridges  needs  to  be  destroyed  by  determining 
which  one  the  enemy  is  using.  This  determination  is  made  by 
identifying  an  enemy  truck  heading  for  the  appropriate 
bridge . 

DDD 

MTWS 

In  DDD,  a  reconnaissance 
aircraft  or  a  satellite  is 
required  to  identify  if  a 
truck  is  hostile  or  neutral. 
Once  this  determination  has 
been  made,  a  coordinated 
attack  is  required  to  destroy 
the  bridge. 

In  MTWS,  aircraft  can  not 
identify  a  ground  target  and 
display  it  as  a  track  on  the 
map.  Satellites  capability 
is  not  implemented  in  MTWS. 
Ground  forces  in  the  area  can 
employ  sensor  nets  or 
visually  identify  the  trucks. 
The  enemy  truck  will  appear 
as  a  company  sized  unit 
instead  of  a  team  size.  The. 
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amount  of  time  required  to 
remove  a  bridge  in  MTWS  is 
directly  proportional  to  the 
Manpower  applied,  given  that 
engineering  units  are  used. 

If  all  the  required  units  (as 
outlined  in  the  operational 
plan)  are  used,  the  bridge 
will  be  removed  in  a  matter 
of  minutes.  If  not,  it  will 
take  significantly  longer  to 
remove  the  bridge. _ 


Task:  Taking  the  Hill 

Requirements:  Coordinated  attacks  are  required  to  capture 

and  hold  the  hill. 

DDD 

MTWS 

This  process  is  similar  to 
the  procedure  used  to  capture 
the  beaches,  except  the 
coordinated  attack  is  limited 
to  one  enemy  unit  instead  of 
two.  Once  the  hill  has  been 
captured,  a  unit  must  hold  it 
by  issuing  the  HOLD  command. 

The  issues  here  are  similar 
to  the  issues  described  for 
capturing  the  beaches .  MTWS 
also  has  the  capability  to 
put  units  into  a  hold  posture 
after  they  have  defeated  red 
forces . 

Task:  Taking  the  Seaport 

Requirements:  Coordinated  attacks  are  required  to  capture 

the  sea  port. 

DDD 

MTWS 

This  process  is  similar  to 

This  process  is  similar  to 

the  beaches  or  the  hill. 

the  beaches  or  the  hill. 

Task:  faking  the  Airport 

1 

Requirements:  Coordinated  attacks  are  required  to  capture 
the  airport. 

DDD 

MTWS 

This  process  is  similar  to 

This  process  is  similar  to 

the  beaches  or  the  hill. 

the  beaches  or  the  hill . 

2 .  Capabilities 

Capability:  Track  Identification 

Requirements:  Players  are  often  required  to  identify 

ground,  sea,  and  air  tracks  to 
hostile  or  neutral. 

determine  whether  they  are 

5' 


MTWS 


DDD 


This  mission  is  performed  by- 
moving  within  sensor  range  to 
the  target  in  question  and 
issuing  an  IDENTIFY  command. 
The  results  of  this  are  then 
automatically  share  with  all 
the  players . 


MTWS  will  automatically 
detect  a  track  by  displaying 
a  purple  rectangle  on  the 
screen.  The  spot  report  log 
has  to  be  monitored  to 
identify  the  type  of  unit, 
and  whether  it  is  hostile  or 
not.  The  visual  information 
is  shared  with  all  the 
players,  but  the  spot  reports 
are  only  displayed  for  the 
detecting  units. _ 


Capability:  Coordinated  Attacks 

Requirements:  The  simulation 

require  coordination  between  B 
not  have  all  the  capabilities 
mission,  they  will  either  rece 
task,  or  they  will  not  succeed 

requires  that  certain  attacks 
lue  forces.  If  the  forces  do 
required  to  accomplish  the 
ive  a  lower  score  for  the 

DDD 

MTWS 

This  procedure  is  enforced 
through  the  software  in  DDD. 
Two  or  more  players  will 
launch  an  attack  as  described 
in  the  "Taking  the  Beaches" 
section.  If  less  than  the 
required  forces  are  applied 
to  the  task,  DDD  will  either 
give  a  low  score  or  will  not 
allow  the  task  at  all. 

MTWS  will  not  prevent  any 
unit  from  attacking  another, 
even  with  inadequate 
resources.  Attack  missions 
will  be  far  more  efficient  if 
the  appropriate  units  are 
applied.  MTWS  does  not  score 
the  results,  but  the  log 
files  can  be  analyzed  to 
learn  the  damage  inflicted  on 
the  enemy  unit,  and  whether 
the  players  used  the  right 
forces  for  the  job. 

Capability:  Medivac  Missions 

Requirements:  Sometimes  units  sustain  casualties  after  an 

attack,  and  a  medivac  mission  is  required  before  the  unit  is 
capable  to  continue  operating. 

DDD 

MTWS 

Launching  a  medivac  mission 
is  as  simple  as  releasing  a 
medivac  asset .  Once  this 
unit  is  operational,  the 

ATTACK  option  is  used  on  the 
wounded  unit.  The  unit  is 
then  restored. 

MTWS  can  support  medivac 
missions,  but  this  capability 
is  difficult  to  employ. 
Additionally,  MTWS  requires 
situation  specific 
information  (such  as  number 
of  wounded  and  killed)  so 
batch  files  could  not  be 
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used.  This  feature  is  not 
currently  implemented. _ 


Capability:  Clearing  Sea  Mines 

Requirements:  Sea  mines  will  likely  block  access  to  one  or 

both  of  the  beaches,  and  need  to  be  cleared  before  the 
operation  can  continue. 

DDD 

MTWS  1 

DDD  will  automatically  stop  a 
ship  from  moving  into  sea 
mines  once  they  have  been 
detected.  DDD  will  display  a 
mine  icon  to  represent  the 
mines  on  the  screen.  A 
minesweeper  needs  to  be  moved 
into  the  area,  and  instructed 
to  remove  the  mines. 

MTWS  will  allow  ships  to 
detect  sea  mines  if  the 
parametric  database  is 
properly  configured. 

Otherwise  the  only  way  to 
find  them  is  to  run  into 
them.  The  firepower  of  the 
mines  can  be  reduced  in  the 
parametric  database  so  the 
damage  to  naval  assets  is  not 
significant.  Ships  will  not 
stop  when  they  encounter  a 
minefield.  The  settings  in 
MTWS  require  an  enemy 
minefield  to  be  displayed  all 
the  time  or  none  of  the  time. 
Minefields  will  not  be 
displayed  on  the  screen  after 
detection.  No  easy  method 
was  determined  to  remove  sea 
mines .  The  sea  mines 
capability  to  disarm  them  was 
researched,  but  not 
implemented. 

Capability:  Clearing  Land  Mines 

Requirements:  Blue  forces  will  encounter  land  mines  at 
"random"  locations  on  some  of  the  roads.  Once  these  mines 
have  been  detected,  and  engineering  unit  is  required  to 
remove  them. 

DDD 

MTWS 

DDD  does  not  allow  players  to 
move  around  the  mines,  or  • 
through  them  until  they  have 
been  removed.  An  engineering 
unit  simply  needs  to  approach 
the  minefield,  and  issue  the 
command  to  remove  the  mines . 

MTWS  will  stop  land  units 
when  they  encounter  a 
minefield.  Unless  there  are 
obstructions,  (which  can 
easily  be  put  in  place) , 
units  can  move  off  the  road 
and  around  the  mine  field. 

An  engineering  unit  is 
required  to  remove  the 
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minefield.  The  amount  of 
time  and  manpower  required  to 
remove  a  minefield  was 
manipulated  in  the  parametric 
database,  so  a  minefield 
could  be  removed  in  a 
reasonable  amount  of  game 
time . 


Capability:  Clearing  Tanks 

Requirements:  Blue  forces  "randomly"  encounter  tanks  which 

must  be  defeated  before  the  mission  can  proceed. 

DDD 

MTWS 

A  coordinated  attack  is 
required  to  remove  a  tank. 

MTWS  functions  similarly  to 
the  other  coordinated  tasks . 
The  tanks  can  be  configured 
so  they  are  easily  defeated. 
This  was  researched,  but  due 
to  time  restraints,  not 
included  in  the  implemented 
version. 

Capability:  Clearing  SAM  Sites 

Requirements:  SAM  sites  must  be  detected,  and  determined  to 

be  non-decoy  or  hostile  before  they  can  be  destroyed. 

Certain  other  tasks  can  not  be  performed  until  a  nearby  SAM 
site  has  been  destroyed. 

DDD 

MTWS 

DDD  will  not  allow  the 
following  on  task  (such  as 
taking  the  port)  to  be 
accomplished  until  the  SAM 
site  has  been  destroyed. 
Coordinated  attacks  are 
required  to  remove  the  SAM 
site . 

MTWS  can  not  enforce  the 
order  of  events,  so  while  a 

SAM  site  may  be  present, 
units  can  still  continue 
other  parts  of  the  mission  at 
increased  risk  to  air  assets. 
MTWS  includes  SAMs  in  its 
database,  but  this  feature 
has  not  been  implemented  yet 
due  to  time  constraints . 

Capability:  Removing  Pop  Up  Targets 

Requirements:  Various  enemy  air  units  appear  on  the  screen 

from  time  to  time.  The  units  can  be  removed  with  a  single 
air  unit,  or  with  naval  gunfire  support 

DDD 

MTWS 

When  the  target  appears,  a 
single  aircraft  or  ship  can 
attack  if  it  is  in  range. 

This  feature  has  not  been 
implemented  yet,  but  could 
easily  be  added  by  including 
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timed  batch  files  to  move 
enemy  artillery  units  in  and 
out  of  range  of  the  Blue 
forces .  These  units  can  be 
configured  to  be  relatively 
weak,  so  they  can  be 
destroyed  by  a  ship  or  a 
single  CAS  mission. _ 


Capability:  Clearing  Hostile  Tracks 

Requirements:  Random  and  hostile  air,  sea,  and  ground 

tracks  will  appear  periodically.  These  units  should  be 
identified  and  then  destroyed. 

DDD 

MTWS 

Ships,  ground  units,  and 
aircraft  have  the  capability 
to  detect  some  or  all  of 
these  tracks.  Neutral  tracks 
may  be  destroyed,  but  it 
lessens  a  teams  overall 
score .  Most  of  these  tracks 
can  be  removed  with  a  single 
unit . 

Time  based  batch  files  can  be 
used  to  automate  the  random 
tracks.  Units  in  MTWS  can 
detect  a  track  if  it  is  in 
sensor  range .  These 
automated  units,  like  other 

Red  force  units  will  be 
configured  so  they  are 
relatively  easy  to  defeat 
with  the  appropriate  units. 
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VII.  CONCLUSIONS 


A.  CONCLUSIONS 

This  thesis  set  out  to  facilitate  and  explore  the 
transition  of  the  A2C2  project  from  Tier  I  experimentation 
to  Tier  II  experimentation  using  the  MTWS  simulation. 

Using  the  method  of  developing  multiple  batch  files  for 
building  the  scenario  and  simplifying  the  simulation,  and 
the  modular  approach  to  building  scenarios,  MTWS  can  easily 
accommodate  modifications  for  subsequent  experiments  with  a 
minimum  of  effort.  The  MTWS  simulation  will  provide  an 
operation  that  is  driven  much  more  by  the  course  of  scenario 
events  than  it  is  by  aspects  of  the  computer  interface. 
This  will  provide  an  accurate  assessment  of  command  and 
control  architectures  which  could  be  mapped  into  real-world 
organizational  structures. 

MTWS  is  a  viable  platform  for  the  continuation  of  the 
A2C2  project.  Because  of  its  detailed  database  that  can 
realistically  structure  every  aspect  of  the  game,  and  its 
stochastic  nature,  it  can  provide  much  more  of  the  real- 
world  uncertainty  that  is  often  referred  to  as  the  "fog  of 
war."  Yet  MTWS  can  still  provide  a  highly  controlled 
environment  that  can  be  used  to  perform  repeatable 
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experiments  that  can  assess  the  effectiveness  of  various 
command  and  control  architectures . 

B .  RECCOMMENDATIONS 

Although  the  author  has  concluded  that  MTWS  can  support 
the  A2C2  project,  several  issues  need  to  be  resolved  or 
investigated  before  the  MTWS  implementation  of  the  A2C2 
scenario  is  ready  for  use  in  the  transition  from  Tier  I  to 
Tier  II  experimentation. 

1.  Red  Forces  and  Neutral  Targets 

Virtually  all  the  Blue  forces  have  been  implemented  in 
the  MTWS,  except  where  noted  in  Chapter  VI.  Many  of  the  Red 
Forces  still  need  to  be  implemented.  These  include  the 
hostile  and  neutral  air  and  sea  traffic  as  well  as  the  pop 
up  artillery  units  that  appear  from  time  to  time  in  the 
scenario.  Additionally,  the  shortcomings  with  enemy  sea 
mine  removal  should  be  resolved. 

2 .  Combat 

Red  and  Blue  forces  have  been  defined  and  equipped  in 
MTWS  so  the  outcome  of  combat  will  usually  be  favorable  for 
Blue  forces  if  the  appropriate  units  are  applied.  The 
outcome  will  be  closer  to  a  draw  if  inadequate  forces  are 
applied.  In  the  case  where  inadequate  forces  are  used 
repeatedly,  the  attrition  rates  will  most  likely  eventually 
eliminate  Red  Forces. 
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The  probability  of  victory  given  the  assigned  units  has 
not  been  assessed.  Closed  loop  trials  could  be  run  on  Red 
Forces  versus  Blue  Forces  to  determine  the  outcome  of  a 
large  number  of  engagements.  This  will  help  determine  a 
realistic  structure  for  Red  and  Blue  forces  so  that  Blue 
forces  will  be  forced  to  fight,  with  desired  attrition 
rates.  It  will  also  help  the  A2C2  analysts  remove  the 
effects  of  the  probabilistic  events  in  MTWS  from  the 
performance  of  the  players. 

3 .  Unbiased  Controller 

MTWS  has  a  certain  set  of  commands  and  capabilities, 
that  allow  an  unbiased  controller  to  have  complete  control 
over  the  simulation  if  necessary.  This  controller  could 
perform  functions  such  as  allowing  minefields  to  be  visible 
after  they  have  been  detected,  or  overriding  MTWS  in  cases 
where  Blue  units  have  been  damaged  beyond  usefulness  or 
killed.  The  controller  could  step  in  any  situation  where 
the  software  or  computer  equipment  have  a  more  significant 
impact  on  the  outcome  of  a  task  or  a  mission  than  they 
should. 

4 .  Dedicated  Controllers 

The  MTWS  concept  was  designed  to  that  the  people  who 
were  being  trained  or  tested  by  it  did  not  need  to  have  any 
knowledge  of  the  MTWS  interface  itself.  Instead,  dedicated 
computer  operators  would  control  MTWS  workstation  and  act  as 
an  interface  between  the  decision  makers  and  the  simulation. 
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While  this  method  might  eliminate  the  need  for  MTWS  training 
for  A2C2  participants,  the  addition  of  dedicated  human 
controllers  could  present  another  variable  that  could  impact 
the  results  of  the  experiment.  Batch  files  that  are  used  to 
automate  tasks,  as  outlined  in  Chapter  IV,  could  be  used  to 
further  simplify  the  usage  MTWS  and  further  reduce  the 
complexity  for  the  operators . 

5.  MARS  Capability 

The  MARS  upgrade  to  MTWS  will  provide  a  wide  array  of 
analysis  tools  to  the  MTWS  package.  Many  of  these  will 
automate  the  task  a  extracting  and  analyzing  data  during  a 
trial  as  well  as  after  a  trial.  [Ref.  2] . 
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APPENDIX  A.  BATCH  FILE  LISTINGS 


This  appendix  provides  a  complete  listing  of  batch  files  and 
their  contents  in  the  current  implementation  of  the  A2C2 
experiment . 


UNIT ;  DEF INE ;  TRK1 ;  C I V ;  C I VI  LI  AN ;  TEAM ;  3  9DXE 110309;  CONT_l ;  ;  S IMUL 
ATED ; FALSE; NO ;$ 

UNIT ;  DEFINE ;  TRK2  ;  C I V ;  C IVILIAN ;  TEAM ;  3  9DXE11 0309;  CONT_l ;  ;  S IMUL 
ATED ; FALSE; NO ;$ 

UNIT ;  DEFINE ;  TRK3  ;  CIV;  CIVILIAN ;  TEAM ;  3 9DXE1 103  0 9  ;  CONT_l ;  ;  S IMUL 
ATED ; FALSE; NO ;$ 

UNIT ;  DEFINE ;  TRK4  ;  CIV;  CIVILIAN ; TEAM ;  3 9DXE11 03 09 ;  CONT_l ;  ;  SIMUL 
ATED ; FALSE; NO ;$ 

UNIT ;  DEFINE ;  TRK5  ;  C I V ;  C I VI L I  AN ;  TEAM ;  3  9DXE 110309;  CONT_l ;  ;  S  IMUL 
ATED ; FALSE; NO ;$ 

UNIT ;  DEFINE ;  TRK6  ;  CIV;  CIVIL  IAN;  TEAM;  39DXE110309 ;  CONT_l ;  ;  SIMUL 
ATED ; FALSE; NO ;$ 

UNIT ;  DEFINE ; TRK7 ;  CIV;  CIVILIAN;  TEAM ;  39DXE1103 09  ;  CONT_l ;  ;  SIMUL 
ATED ; FALSE; NO ;$ 

UNIT; DEFINE ;  TRK8  ;  CIV;  CIVILIAN; TEAM;  39DXE1103  09  ;  CONT_l ;  ;  SIMUL 
ATED ; FALSE; NO ;$ 

UNIT ; DEFINE ;  TRK9 ;  CIV;  CIVILIAN; TEAM ;  3 9DXE11 03 0 9 ;  CONT_l ;  ;  SIMUL 
ATED ; FALSE; NO ;$ 

UNIT ;  DEFINE ;  TRK1 0  ;  CIV ;  MOTOR_TRAN S PORT ;  SECTION ;  4 8DVG2  0  9 0  54  ;  AG 
CON_l ;  ;  S IMULATED  ; 

FALSE; NO ;$ 

ASSETS ; UPDATE ; TRK1 ; TROOPS ; { 0 12 ; HEALTHY ; } $ 

ASSETS ; UPDATE ; TRK2 ; TROOPS ; ( 0 1 2 ; HEALTHY ; j  $ 

ASSETS ; UPDATE ; TRK3 ; TROOPS ; 1 012; HEALTHY ; } $ 

ASSETS ; UPDATE ; TRK4 ; TROOPS ; { 0 12 ; HEALTHY ; j  $ 

ASSETS ; UPDATE ; TRK5 ; TROOPS ; j  012 ; HEALTHY;  $ 

ASSETS ; UPDATE ; TRK6 ; TROOPS ; { 0 12 ; HEALTHY ; } $ 

ASSETS ; UPDATE ; TRK7 ; TROOPS ; { 0 12 ; HEALTHY ; } $ 

ASSETS ; UPDATE ; TRK8 ; TROOPS ; 1 0 12 ; HEALTHY ; 1  $ 

ASSETS ; UPDATE ; TRK9 ; TROOPS ; { 0 12 ; HEALTHY ; } $ 

ASSETS ;  UPDATE  ;-TRKl  0  ;  TROOPS ;  {  0 12  ;  HEALTHY ;  }  $ 

ASSETS ; UPDATE ; TRK1 ; ASSET ; ( 012 . 5 -TRUCK ; 1 ; OPERATIONAL  } $ 

ASSETS ; UPDATE ; TRK2 ; ASSET ; ( 012 . 5 -TRUCK; 1 ; OPERATIONAL  ) $ 
ASSETS; UPDATE ;TRK3 ;ASSET;  012 . 5-TRUCK; 1 ; OPERATIONAL;  j $ 

ASSETS ; UPDATE ; TRK4 ; ASSET; i 012 . 5 -TRUCK; 1 ; OPERATIONAL; }$ 
ASSETS; UPDATE ;TRK5; ASSET;  012 . 5- TRUCK; 1 ; OPERATIONAL; } $ 
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ASSETS 

ASSETS 

ASSETS 

ASSETS 

ASSETS 

ASSETS 

ASSETS 

ASSETS 

ASSETS 

ASSETS 

ASSETS 

ASSETS 

ASSETS 

ASSETS 

ASSETS 


;  UPDATE ; 
/UPDATE; 
/UPDATE; 
;  UPDATE ; 
;  UPDATE ; 
/UPDATE; 
/UPDATE; 
/UPDATE; 
/UPDATE; 
;  UPDATE ; 
/UPDATE; 
/UPDATE; 
/UPDATE; 
/UPDATE; 
/UPDATE; 


TRK6 /ASSET ; 
TRK7 /ASSET; 
TRK8 /ASSET ; 
TRK9 /ASSET; 


012. 5-TRUCK; 1/ OPERATIONAL; }$ 
012 . 5 -TRUCK; 1 /OPERATIONAL; j  $ 
012 . 5 -TRUCK; 1 ; OPERATIONAL ; j  $ 
012. 5-TRUCK; 1 /OPERATIONAL; }$ 
TRK1 0 ; AS  SET ; { 0 1 2 . 5 - TRUCK ; 1 ; OPERATIONAL ; } $ 
TRK1; FUEL; 500;$ 

TRK2; FUEL; 500;$ 

TRK3; FUEL; 500;$ 

TRK4; FUEL; 500;$ 

TRK5; FUEL; 500;$ 

TRK6; FUEL; 500;$ 

TRK7; FUEL; 500;$ 

TRK8; FUEL; 500;$ 

TRK9; FUEL; 500;$ 

TRK1 0 ; FUEL ; 5  0  0  ;  $ 


a2c2_run_trucks 

UNIT ; LOCATE ; TRK1 ; 5  2  SEQ1 2  8 1 1 9 ; $ 

UNIT ; LOCATE ; TRK3 ; 52SEQ12  8 119 ; $ 

UNIT ; LOCATE ; TRK7 ; 52SEQ12  8 11 9 ; $ 

UNIT ; LOCATE ; TRK1 0 ; 5  2  SEQ1 13127;$ 

UNIT /MISSION; TRK1 /MOVE ; COLUMN; ; MV_PLANS ; NO ; ; ; 241913ZFEB98 ; {0 
5RD4 ; ; 52SEQ203 076 ; ; 

RD5 ; ; RD1 ; ; 52SEQ210025 ; ; }$ 

UNIT ; MISSION; TRK3 ; MOVE /COLUMN; ; MV_PLANS ; NO ; ; ; 241917ZFEB98 ; {0 
5RD4 ; ; 52SEQ2  03  076 ; ; 

RD5 ; ; RD1 ; ; 52SEQ210025 ; ; }$ 

UNIT ; MI SS ION ;TRK7; MOVE /COLUMN; ; MV_PLANS ; NO ; ; ; 241917ZFEB98 ; {0 
5RD4 ; ; 52SEQ203076 ; ; 

RD5 ; ; RD1 ; ; 52SEQ210025 ; ;}$ 

UNIT/MISSION/TRK10 /MOVE; COLUMN; ; MV_PLANS ; NO ; ; ; 241928ZFEB98 ; { 
05RD4 ; ; 52SEQ203076 ; 

; RD5 ; ;RD1; ; 52SEQ210025 ; ; }$ 

UNIT; LOCATE ; TRK2 ;52SEQ233160;$ 

UNI T ; LOCATE ; TRK4 ; 5  2  SEQ2 33160;$ 

UNIT ; LOCATE ; TRK5 ; 52SEQ233 16  0 ; $ 

UNIT ; LOCATE ; TRK6 ; 52SEQ23  3 16  0 ; $ 

UNIT ; LOCATE ; TRK8 ; 5  2  SEQ23 3160;$ 

UNIT ; LOCATE ; TRK9 ; 5  2  SEQ2 33160;$ 

UNIT; MISSION; TRK2; MOVE /COLUMN; ; MV_PLANS ; NO ; ; ; 241914ZFEB98 ; {0 
6RD3 ; /52SEQ221078 ; ; 

RD5 ; ; 52SEQ218066 ; ;RD1; ; 52SEQ210025 ; ; }$ 

UNIT;MISSION;TRK4 ; MOVE ; COLUMN ; ; MV_PLANS ; NO ; ; ; 241917ZFEB98 ; {0 
6RD3 ; ; 52SEQ221078 ; ; 

RD5 ; ; 52SEQ218066 ; ;RD1; ; 52SEQ210025 ; ; }$ 

UNIT; MISSION; TRK5; MOVE /COLUMN; ; MV_PLANS ; NO ; ; ; 241920ZFEB98 ; {0 
6RD3 ; ; 52SEQ221078 ; ; 

RD5 ; ; 52  SEQ2 18066; ;RD1; ; 52SEQ210025 ; ; }$ 

UNIT ; MISSION ;TRK6; MOVE /COLUMN; ; MV_PLANS ; NO ; ; ; 241924ZFEB98 ; {0 
6RD3 ; ; 5  2  SEQ2  21078; ; 

RD5 ; ; 52SEQ218066 ; ;RD1; ; 52SEQ210025 ; ; }$ 
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UNIT ; MISSION; TRK8 ;MOVE ; COLUMN; ; MV_PLANS ; NO ; ; ; 241927ZFEB98 ; { 0 
6RD3 ; ; 52SEQ221078 ;  ; 

RD5 ; ; 52SEQ218066 ; ;RD1; ; 52SEQ210025 ; ; }$ 

UNIT ; MISSION; TRK9 /MOVE ; COLUMN; ; MV_PLANS ; NO ; ; ; 241929ZFEB98 ;  {0 
6RD3 ; ; 52SEQ221078 ; ; . 

RD5 ; ; 5  2  SEQ2 18066; ;RD1; ; 52SEQ210025 ; ; }$ 
a2c2_red_mines 

CE; CONSTRUCT /MINES; ; ; OBSTACLE /MINE; AG; M-FLD-AP- 
LOW; { 0452SEQ206011 ; 52SEQ212004 ; 

52SEQ207002 ; 52SEQ201009 ; }$ 

a2 q2  IZJSd  ngft 

UNIT? DEFINE ;  HILL_DEFENSE ;  AG ;  INFANTRY ;  TEAM ;  52 SEQ2 85118;  AGCON_ 
1 ;  ;  S IMULATED ;  FALSE ;  NO ;  $ 

UNIT; DEFINE ;NB_DEFENSE; AG;  INFANTRY ; TEAM ;  52SEQ269087 ;AGCON_l; 
; S IMULATED ; FALSE ; NO ; $ 

UNIT  /  DEFINE ;  SB_DEFENSE ;  AG ;  INFANTRY ;  TEAM ;  5 2 SEQ2 23020;  AGCON_l  ; 
; S IMULATED ; FALSE ; NO ; $ 

UNIT ;  DEFINE ;  PORT_DEFENSE ;  AG ;  INFANTRY ;  TEAM ;  52  SEQ3 28122;  AGCON_ 
1 ; ; S IMULATED ; FALSE ; NO ; $ 

UNIT; DEFINE ;AIRPORT_DEFENSE; AG;  INFANTRY ;  TEAM ;  52SEP145983  ;AGC 
ON_l ; ; S IMULATED ; FALSE ; NO ; $ 

ASSETS ; UPDATE ; NB_DEFENSE ; TROOPS ;  {  0 1 8  ; HEALTHY ; ) $ 

ASSETS ; UPDATE ; SB_DEFENSE ; TROOPS ; { 0 1 8 ; HEALTHY ; } $ 

ASSETS; UPDATE ;AIRPORT_DEFENSE; TROOPS; { 018 /HEALTHY; }$ 

ASSETS ;  UPDATE ; HILL_DEFENSE ; TROOPS ; { 0 1 8 ; HEALTHY ; } $ 

ASSETS ; UPDATE ; PORT_DEFENSE ; TROOPS ; { 0 1 8 ; HEALTHY ; } $ 

ASSETS ; UPDATE ; SB_DEFENSE ; WATER ; 5  0  0 ; $ 

ASSETS ; UPDATE ; NB_DEFENSE ; WATER ; 5  0  0 ; $ 

ASSETS ; UPDATE ; HILL_DEFENSE ; WATER ; 5  0  0 ; $ 

ASSETS ; UPDATE ; PORT_DEFENSE ; WATER ; 5  0  0 ; $ 

ASSETS ; UPDATE ; AIRPORT_DEFENSE ; WATER ; 5  0  0 ; $ 

ASSETS ; UPDATE ; NB_DEFENSE ; RATIONS ; 2  0  0 ; $ 

ASSETS ; UPDATE ; SB_DEFENSE ; RATIONS ; 2  0  0 ; $ 

ASSETS ; UPDATE ; AIRPORT_DEFENSE ; RATIONS ; 2  0  0 ; $ 

ASSETS ; UPDATE ; PORT_DEFENSE ; RATIONS ; 2  0  0 ; $ 

ASSETS ; UPDATE ; HILL_DEFENSE ; RATIONS ; 2  0  0 ; $ 

ASSETS ;  UPDATE ;  NB_DEFENSE  /  ASSET ;  {  02M- 16  ;  3  ;  OPERATIONAL ;  SA- 
BALL ; 1 0  0  0 ; OPERATIONAL ; } $ 

ASSETS ;  UPDATE ;  SB_DEFENSE ;  ASSET ;  {  02M- 1 6  ;  3  ;  OPERATIONAL ;  SA- 
BALL ; 1 0  0  0 ; OPERATIONAL ; } $ 

ASSETS ;  UPDATE ;  AIRPORT_DEFENSE ;  ASSET ;  {  02M-  6 ;  3  ;  OPERATIONAL ;  SA- 
BALL ; 1 0 0 0 ; OPERATIONAL ;} $ 

ASSETS ; UPDATE ;HILL_DEFENSE; ASSET;  {  02M-16  ;  3  /  OPERATIONAL;  SA- 
BALL ; 1 0 0 0 ; OPERATIONAL ;} $ 

ASSETS ;  UPDATE ; PORT_DEFENSE ; ASSET ; { 0  2M- 1 6 ; 3 ; OPERATIONAL ; SA- 
BALL ; 1 0  0  0 ; OPERATIONAL ; } $ 


a2c2_p5_sof 
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UNIT ; DEFINE ; P5_S0F ; LF ; ENGINEER ; PLATOON; 52  SEQ2 17094; MANCON_S ; 
; SIMULATED ; FALSE ; YES ; USMC ; ENG_BRIDGE ; $ 

a  2 C 2_p  5_eng 

UNIT7DEFINE ; P5_ENG ; LF ; ENGINEER ; COMPANY ; 5  2  SEQ2 11081; MANCON_6 ; 
; SIMULATED ; FALSE ; YES ; USMC ; CMB_ENG ; $ 

&2c«2  p5  Cjifll 

AIRCRAFT; DEFINE; FA-18 ; P1_CV1_AIRSQUAD ; 0002 ; QUANTITY; 2 ; $ 

a2c2_p4_vfl 

AIRCRAFT; DEFINE; F-14 ; P1_CV1_AIR_SQUAD; 0001 ;QUANTITY; 2 ; $ 
a2c2_p4_mv22_p4_lhal 

AIRCRAFT ; DEFINE ; MV- 22 ; P4_LHA1_AIRSQUAD ; 2222 ; QUANTITY ; 1 ; $ 

a2c2_p4_jmv22_p2_lpdl 

AIRCRAFT; DEFINE; MV- 2 2 ; P2_LPD1_AIRSQUAD; 2222 ; QUANTITY; 1 ; $ 
a2c2_p4_med2_lpdl 

AIRCRAFT ; DEFINE ; UH- ; P2_LPD1_AIRSQUAD ; 5555 ; INDIVIDUAL; { Oil ; } $ 
a2c2_p4_med2_lhal 

AIRCRAFT ; DEFINE ; UH- 1 ; P4_LHA1_AIRSQUAD ; 5555 ; INDIVIDUAL ; 
{011;}$ 

a2  c2_p4_medl_lhal 

AIRCRAFT ; DEFINE ; UH-1 ; P4_LHA1_AIRSQUAD ; 5555 ; INDIVIDUAL ; 
{011;}$ 


a2c2  p4  Thai 

UNIT7DEFINE ; P4_LHA1 ; LF ; SHI P ; COMPANY ; 5  2  SEQ2 60000; MANCON_5 ; ; S I 
MULATED ; FALSE ; YES ; USN ; LHA ; $ 

UNIT ; DEFINE ; P4_LHA1_AIRSQUAD ; LF ; AIR_SQUADRON; COMPANY ; P4_LHA1 
; AIRCON ;; SIMULATED ; FALSE ; YES ; USMC ; MASS ; $ 

UNIT ; DEFINE ; P4_LHA1_AIRSUPPLY; LF ; SUPPLY ; SQUADRON ; P4_LHA1 ; AIR 
CON ; ; SIMULATED ; FALSE ; NO ; $ 

ASSETS ; UPDATE ; P4_LHA1_AIRSUPPLY ; TROOPS ; { 0 15  0 ; HEALTHY ; } $ 
ASSETS ;  UPDATE ;  P4_LHA1_AIRSUPPLY ;  FUEL  ,-1000000;$ 

ASSETS ; UPDATE ; P4_LHA1_AIRSUPPLY ; RATIONS ; 5  0  0  0 ; $ 

ASSETS ; UPDATE ; P4_LHA1_AIRSUPPLY ; WATER ; 5  0  0  0  0 ; $ 

AIRFIELD ; DEFINE ; P4_LHA1 ; P4_LHA1 ; OPEN ; ; P4_LHA1_AIRSUPPLY ; { 01P 
4_LHA1_AIRSQUAD ; } { 00 ; } $ 

a2c2_p4_inf2_p4_lhal 

UNIT ; DEFINE ; P4_INF2 ; LF ; INFANTRY ; PLATOON ; P4_LHA1 ; MANCON_5 ; ; SI 
MULATED ; FALSE ; YES ; USMC ; IFY_3 ; $ 

a2c2_p4_inf 2_p2_lpdl 

UNIT ; DEFINE ; P4_INF2 ; LF ; INFANTRY ; PLATOON; P2_LPD1 ; MANCON  5 ; ; SI 
MULATED ; FALSE; YES; USMC; I FY  3;$ 


70 


a2c2_p4_infl_p4_lhal 

UNIT ; DEFINE ; P4_INF1 ; LF ; INFANTRY ; PLATOON; P4_LHA1 ; MANCON_5 ; ; SI 
MULATED ; FALSE ; YES ; 

USMC; IFY_3 ; $ 

a2c2 j4^infl_p2_lpdl_southbeach 
AIR_MISSION ; DEFINE ; LPD_LAND_P4_INF1_SB ; MV- 
22 ; 1 ; P2_LPD1_AIRSQUAD ; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 01SB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ; DEFINE ; LPD_LAND_P4_INF1_SB ; LF ; P2_LPD1 ; USE_OF_AIRCRAFT 
; {01P4_INF1; }SB; 

MV-22 ; 1 ; $ 

SERIAL ;  ASSOCIATE ;  LPD_LAND_P4_INF1_SB ;  LPD_LAND_P4_INF1_SB ;  $ 

a2c2_p4_inf l_p2_lpdl_northbeaeh 

AIR_MI SS ION ; DEF INE ; LPD_LAND_P4_INF1_NB ; MV- 

22  ;  1  ;  P2_LPD1_AIRSQUAD; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 0 1NB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ; DEFINE ; LPD_LAND_P4_INF1_NB ; LF ; P2_LPD1 ; USE_OF_AIRCRAFT 
; { 01P4_INF1 ; }NB ; 

MV-22 ;1;$ 

SERIAL ; ASSOCIATE ; LPD_LAND_P4_INF1_NB ; LPD_LAND_P4_INF1_NB ; $ 
a2c2_p4_inf l_p2_lpdl 

UNIT ; DEFINE ; P4_INF1 ; LF ; INFANTRY ; PLATOON ; P2_LPD1 ; MANCON_5 ; ; S I 
MULATED ; FALSE ; YES ; 

USMC; IFY_3 ; $ 

a2c2_p4_eas2 

AIRCRAFT ; DEFINE ; FA- 1 8 ; P1_CV1_AIRSQUAD ; 0  0  0  2 ; QUANTITY ; 2 ; $ 


a2c2_p4_casl 

AIRCRAFT ; DEFINE ; FA- 1 8 ; P1_CV1_AIRSQUAD ; 0  0  02 ; QUANTITY ; 2 ; $ 
a2c2  p4_ahl - l_p2_lpdl 

AIRCRAFT ; DEFINE ; AH- 1W ; P2_LPD1_AIRSQUAD ; 4444 ; QUANTITY ; 2 ; $ 
AIRCRAFT ; DEFINE ; AH- 1W ; P2_LHA1_AIRSQUAD ; 44  44 ; QUANTITY ; 2 ; $ 

a2c2_p4_aaavl_on_p4_lhal 

UNIT ; DEFINE ; P4_AAAV1 ; LF ; AS S AULT_AMPH I B IAN ; PLATOON ; P4_LHA1 ; MA 
NCON_5 ; ; SIMULATED ; 

FALSE ; YES ; USMC ; AAV ; $ 

a2c2_p4_aaavl_Qn=p2^1hal 

UNIT ; DEFINE ; P4_AAAV1 ; LF ; ASSAULT_AMPHIB IAN ; PLATOON ; P2_LHA1 ; MA 
NCON_5  ;  ;  S IMULATED  ; 

FALSE ; YES ; USMC ; AAV ; $ 

a2c2_p3_vfl 

AIRCRAFT ; DEFINE ; F - 14 ; P1_CV1_AIR_SQUAD ; 0  0  0 1 ; QUANTITY ; 2 ; $ 
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a2c2_p3_sof 

UNIT ; DEFINE ; P3_S0F ; LF ; ENGINEER ; PLATOON ; 52SEQ2 17 0 94 ; MANCON  4 ; 
; S IMULATED ; FALSE ; 

YES ; USMC ; ENG_BRIDGE ; $ 

a2c2_p3_mv22b_p3_lpdl 

AIRCRAFT /DEFINE; MV- 2 2 ; P3_LPD1_AIRSQUAD; 2222 /QUANTITY; 1 ; $ 


a2c2_p3_mv22b_p2_lpdl 

AIRCRAFT ; DEFINE ; MV-22 ; P2_LPD1_AIRSQUAD ; 2222 ; QUANTITY; 1 ; $ 
a2e2_p3_mv22a_p3_lpdl 

AIRCRAFT ;  DEFINE ;  MV- 22  ;  P3_LPD1_AIRSQUAD ;  2222  ;  QUANTITY;  1 ;  $ 

a2e2_p3_mv22a_p2_lpdl 

AIRCRAFT /DEFINE; MV-22 ; P2_LPD1_AIRSQUAD; 2222 /QUANTITY; 1 ; $ 

a2c2__p3_med2_lhal 
AIRCRAFT ; DEFINE ;  UH- 

1 ; P2_LHA1_AIRSQUAD ; 5555 ; INDIVIDUAL ; { 0 1 1 ; } $ 

a2c2_p3_medl_lpdl 
AIRCRAFT ; DEFINE ; UH- 

1 ; P3_LPD1_AIRSQUAD; 5555 ; INDIVIDUAL ; { Oil ; } $ 

a2c2_p3_medl_lhal 
AIRCRAFT ; DEFINE ; UH- 

1 ; P2_LHA1_AIRSQUAD; 5555 ; INDIVIDUAL; {Oil ; } $ 

a2c2_p3_lpdl 

UNIT ; DEFINE ; P3_LPD1 ; LF ; SHIP ; COMPANY ; 52SEQ2  84  0  3  0 ; MANCON_4 ; ; SI 
MULATED ; FALSE ; YES ; CIS ; LPD_AG_CLASS ; $ 

UNIT ;  DEFINE ;  P3_LPD1_AIRSQUAD ;  LF ;  AIR_SQUADRON;  COMPANY;  P3_LPD1 
/AIRCON; ; SIMULATED; FALSE ; YES ;USMC;MASS ; $ 

UNIT;  DEFINE ; P3_LPD1_AIRSUPPLY ; LF ; SUPPLY ; SQUADRON ; P3_LPD1 ; AIR 
CON ; ; S I MULATED ; FALSE ; NO ; $ 

ASSETS; UPDATE ;P3_LPD1_AIRSUPPLY; TROOPS; { 0150 ; HEALTHY; } $ 
ASSETS ; UPDATE ; P3_LPD1_AIRSUPPLY ; FUEL ; 1000000;$ 

ASSETS ; UPDATE ; P3_LPD1_AIRSUPPLY ; RATIONS ; 5  0  0  0 ; $ 

ASSETS ; UPDATE ; P3_LPD1_AIRSUPPLY ; WATER ; 5  0  0  0  0 ; $ 

AIRFIELD ; DEFINE ; P3_LPD1 ; P3_LPD1 ; OPEN; ; P3_LPD1_AIRSUPPLY; 

{ 0 1P3_LPD1_AIRSQUAD ; } { 0  0 ; } $ 

a2c2_p3,-.inf5_p2_lhal 

UNIT ;  DEFINE ; P3_INF5 ; LF ; INFANTRY; PLATOON; P2_LHA1 ; MANCON_4 ; ; SI 
MULATED ; FALSE ; YES ; USMC ; HMG ; $ 

a2c2_p3_inf  4_p2_lhal_sout:hbaaeh 
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AIR_MlSSION;  DEFINE ;  LHA_LAND_P3_INF4_SB ;  MV- 
2  2 ; 1 ; P2_LHA1_AIRSQUAD ; P2_LHA1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 0 1SB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ;  DEFINE ;  LHA_LAND_P3_INF4_SB ;  LF ;  P2_LHA1 ; USE_OF_AIRCRAFT 
; { 0 1P3_INF4 ; } SB ; MV- 22 ; 1 ; $ 

SERIAL ;  ASSOCIATE ;  LHA_LAND_P3_INF4_SB ;  LHA_LAND_P3_INF4_SB ;  $ 

a2g2_j3_inf4_p2_lhal_northbeach 
AIR_MISSION;  DEFINE ;  LHA_LAND_P3_INF4_NB ;  MV- 
22 ; 1 ; P2_LHA1_AIRSQUAD ; P2_LHA1 ; ; ; ; STS ; 

TAKE_OFF; ; { 0 1NB ; MEDIUM ; UNIT_DROP ; }$ 

SERIAL ;  DEFINE ;  LHA_LAND_P3_INF4_NB ;  LF ;  P2_LHA1 ;  USE_OF_AIRCRAFT 
; { 01P3_INF4 ; }NB ; MV-22 ; 1 ; $ 

SERIAL ;  ASSOCIATE ;  LHA_LAND_P3_INF4_NB ;  LHA_LAND_P3_INF4_NB ;  $ 

a2c2_p3-^inf4_j?2_lhal 

UNIT ;  DEFINE ;  P3_INF4  ;  LF ;  INFANTRY ;  PLATOON ;  P2_LHA1 ;  MANCON_4  ;  ;  S I 
MULATED ; FALSE ; YES ; 

USMC ; IFY_3 ; $ 

a2c2_p3_inf 3_p2_lpdl_southbeaeh 
AIR_MISSION;  DEFINE ;  LPD_LAND_P3_INF3_SB  ;MV- 
22 ; 1 ; P2_LPD1_AIRSQUAD ; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 0 1SB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ;  DEFINE ;  LPD_LAND_P3_INF3_SB ;  LF ;  P2_LPD1 ; USE_OF_AI RCRAFT 
; { 01P3_INF3 ; }SB ; MV-22 ; 1 ; $ 

SERIAL ;  ASSOCIATE ;  LPD_LAND_P3_INF3_SB ;  LPD_LAND_P3_INF3_SB ;  $ 


a2g2_p3_inf 3_p2_lpdl_nortKbeach 
AIR_MISSION ;  DEFINE ;  LPD_LAND_P3_INF3_NB ;  MV- 
22  ;  1 ;  P2_LPD1_AIRSQUAD ; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 0 1NB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ;  DEFINE  ;  LPD_LAND_P3_INF3_NB ;  LF ;  P2_LPD1 ; USE_OF_AIRCRAFT 
; { 01P3_INF3 ; }NB ;MV-22 ; 1 ; $ 

SERIAL ;  ASSOCIATE ;  LPD_LAND_P3_INF3_NB ;  LPD_LAND_P3_INF3_NB ;  $ 

a2c2_p3_inf 3_p2_lpdl 

UNIT ;  DEFINE ;  P3_INF3  ;  LF ;  INFANTRY ;  PLATOON ;  P2_LPD1 ;  MANCON_4  ;  ;  SI 
MULATED ; FALSE ; YES ; USMC ; IFY_3 ; $ 

a2c2_p3_inf  2_p3_lpdl_southl?eaGh 
AIR_MISSION;  DEFINE ;  LPD_LAND_P3_INF2_SB ;  MV- 
22  ;  1 ;  P3_LPD1_AIRSQUAD ; P3_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 01SB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ;  DEFINE ;  LPD_LAND_P3_INF2_SB ;  LF ;  P3_LPD1 ; USE_OF_AI RCRAFT 
; { 0 1P3_INF2 ; } SB ; MV-22 ; 1 ; $ 

SERIAL  /  ASSOCIATE ;  LPD_LAND_P3_INF2_SB ;  LPD_LAND_P3_INF2_SB ;  $ 

a2c2_p3_inf2_p3_lpdl_northbeach 

AIR_MISSION;  DEFINE ;  LPD_LAND_P3_INF2_NB ;  MV- 
22  ;  1 ;  P3_LPD1_AIRSQUAD ; P3_LPD1 ; ; ; ; STS ; 
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TAKE_OFF ; ; { 0 1NB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ;  DEFINE ;  LPD_LAND_P3_INF2_NB ;  LF ;  P3_LPD1 ;  USE_OF_AIRCRAFT 
; { 01P3_INF2 ; }NB ;MV-22 ; 1 ; $ 

SERIAL ;  ASSOCIATE ;  L PD_LAND_P 3 _ I NF 2 _NB ;  LPD_LAND_P 3 _ I NF 2 _NB ;  $ 

a2c2_p3_inf2_p2_lpdl_8Quthbeach 
AIR_MISSION; DEFINE ; LPD_LAND_P3_INF2_SB ;MV- 
22 ; 1 ; P2_LPD1_AIRSQUAD ; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 01SB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ;  DEFINE ;  LPD_LAND_P3_INF2_SB ;  LF ;  P2_LPD1 ;  USE_OF_AIRCRAFT 
; {01P3_INF2 ; } SB; MV- 2 2 ; 1 ;$ 

SERIAL ;  ASSOCIATE ;  LPD_LAND_P3_INF2_SB ;  LPD_LAND_P3_INF2_SB ;  $ 


a2c2_p3_inf 2_p2_lpdl_northbeach 
AIR_MISSION; DEFINE ; LPD_LAND_P3_INF2_NB ; MV- 
2  2 ; 1 ; P2_LPD1_AIRSQUAD ; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 0 1NB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ;  DEFINE ;  LPD_LAND_P 3 _ I NF2_NB ;  LF ;  P2_LPD1 ;  USE_OF_AI RCRAFT 
; { 01P3_INF2 ; }NB;MV-22 ; 1 ; $ 

SERIAL ;  ASSOCIATE ;  LPD_LAND_P3_INF2_NB ;  LPD_LAND_P3_INF2  NB ;  $ 


a2e2_p3_lnf2  p2_lpdl 

UNITTdEFINE ; P3_INF2 ; LF ; INFANTRY ; PLATOON ; P2_LPD1 ; MANCON_4 ; ; S I 
MULATED ; FALSE ; YES ; USMC ; I FY_3 ; $ 

a2c2_p3_infl_p3_lpdl_soufchbeaeh 
AIR_MISSION; DEFINE ; LPD_LAND_P3_INF1_SB ; MV- 
2  2 ; 1 ; P2_LPD1_AIRSQUAD ; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; {01SB;MEDIUM;UNIT_DROP; }$ 

SERIAL ;  DEFINE ;  LPD_LAND_P3_INF1_SB ;  LF ;  P3_LPD1 ;  USE_OF_AIRCRAFT 
; { 01P3_INF1 ; } SB; MV- 2 2 ; 1 ; $ 

SERIAL; ASSOCIATE ;LPD_LAND_P3_INF1_SB;LPD_LAND  P3  INF1  SB;$ 


a2r*2  p3  infl_p3  l.pdl  nnrhhhpanh 

AIR_MI SS I ON ; DEFINE ; LPD_LAND_P 3 _I NF 1_NB ; MV- 

22 ; 1 ; P3_LPD1_AIRSQUAD ; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 0 1NB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ;  DEFINE ;  LPD_LAND_P3_INF1_NB ;  LF ;  P3_LPD1 ;  USE_OF_AI  RCRAFT 
; { 01P3_INF1 ; }NB;MV-22 ; 1 ; $ 

SERIAL ;  ASSOCIATE ;  LPD_LAND_P3_INF1_NB ;  LPD_LAND_P3_INF1_NB  ;  $ 

a2c2_p3_^infl_p3_lpdl 

UNIT /DEFINE; P3_INF1 ; LF ; INFANTRY; PLATOON; P3_LPD1 ;MANCON_4 ; ; SI 
MULATED ; FALSE ; YES ; USMC ; I FY_3 ; $ 

a2e2_p3_infl_p2_lpdl_southbeaGh 
AIR_MISSION; DEFINE ; LPD_LAND_P3_INF1_SB ; MV- 
2  2 ; 1 ; P2_LPD1_AIRSQUAD ; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 0 1SB ; MEDIUM ; UNIT_DROP ; } $ 
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SERIAL ;  DEFINE ;  LPD_LAND_P3_INF1_SB ;  LF. ;  P2_LPD1 ;  USE_OF_AIRCRAFT 
; { 01P3_INF1 ; } SB; MV- 22 ; 1 ; $ 

SERIAL ; ASSOCIATE ; LPD_LAND_P3_INF1_SB ; LPD_LAND_P3_INF1_SB ; $ 

a2c2_p3_infl_p2_lpdl_nortlibeach 

AIR_MISSION; DEFINE; LPD_LAND_P3_INF1_NB ;MV- 
2  2 ; 1 ; P2_LPD1_AIRSQUAD ; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 0 1NB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ; DEFINE ; LPD_LAND_P3_INF1_NB ; LF ; P2_LPD1 ; USE_OF_AIRCRAFT 
; { 01P3_INF1 ; }NB ;MV-22 ; 1; $ 

SERIAL ; ASSOCIATE ; LPD_LAND_P3_INF1_NB ; LPD_LAND_P3_INF1_NB ; $ 
a2c2_p3_lnfl_p2_lpdl 

UNIT ; DEFINE ; P3_INF1 ; LF ; INFANTRY ; PLATOON; P2_LPD1 ; MANCON_4 ; ; SI 
MULATED ; FALSE ; YES ; USMC ; I FY_3 ; $ 

a2c2_p3_eng 

UNIT ; DEFINE ; P3_ENG ; LF ; ENGINEER ; COMPANY ; 5  2  SEQ2  23  087; MANCON_4 ; 
; S IMULATED ; FALSE ; YES ; USMC ; CMB_ENG ; $ 

a2c2_p3_casl 

AIRCRAFT ; DEFINE ; FA- 1 8 ; P1_CV1_AIR_SQUAD ; 0  0  0  2 ; QUANTITY ; 2 ; $ 
a2c2_p3_aaav3_on_p2_lpdl 

UNIT ;  DEFINE ;  P3_AAAV3  ; LF ;  AS S AULT_AMPH I B IAN ;  PLATOON;  P2_LPD1 ; MA 
NCON_4 ; ; SIMULATED ; FALSE ; YES ; USMC ; AAV ; $ 

a2 c2_p3_aaav2_on_p2_lhal 

UNIT;  DEFINE ;  P3_AAAV2  ;  LF ;  ASSAULT_AMPHIB IAN ;  PLATOON;  P2_LHA1  ;MA 
NCON_4 ; ; S IMULATED ; FALSE ; YES ; USMC ; AAV ; $ 

a2c2_p3_aaavl_on_p3_lpdl 

UNIT ;  DEFINE ;  P3_AAAV1 ;  LF ;  AS  S  AULT_AMPH  I B I  AN ;  PLATOON;  P3_LPD1  ;MA 
NCON_4 ; ; S IMULATED ; FALSE ; YES ; USMC ; AAV ; $ 

a2c2_p3_aaavl_on_p2_lhal 

UNIT ;  DEFINE ;  P3_AAAV1 ;  LF ;  ASSAULT_AMPH I B IAN ;  PLATOON;  P2_LHA1 ; MA 
NCON_4 ; ; SIMULATED ; FALSE ; YES ; USMC ; AAV ; $ 

a2n2_p2  vfl 

AIRCRAFT ; DEFINE ; F-14 ; P1_CV1_AIRSQUAD ; 0001 ; QUANTITY; 2 ; $ 
a2c2_p2_sof 

UNIT ; DEFINE ; P2_SOF ; LF ; ENGINEER ; PLATOON ; 52  SEQ2 17094; MANCON_3 ; 

; S IMULATED ; FALSE ; YES ; USMC ; ENG_BRIDGE ; $ 

a2e2_p2_mv22_p2_lhal 

AIRCRAFT ; DEFINE ; MV-22 ; P2_LHA1_AIRSQUAD ; 2222 ; QUANTITY; 1 ; $ 
a2c2_p2_med3_lhal 
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AIRCRAFT ; DEFINE ; UH - 

1;P2_LHA1_AIRSQUAD; 5555; INDIVIDUAL; {013; }$ 

a2c2Ljp2_med2_lhal 

AIRCRAFT ; DEFINE ; UH- 

1 ; P2_LHA1_AIRSQUAD ; 5555 ; INDIVIDUAL; { 012 ; } $ 

a2c2_p2_medl_lpdl 
AIRCRAFT ; DEFINE ; UH- 

1 ; P2_LPD1_AIRSQUAD ; 5555 ; INDIVIDUAL; { Oil ; } $ 


a2e2_p2_lpdl 

UNIT ; DEFINE ; P2_LPD1 ; LF ; SHI P ; COMPANY ; 52  SEQ2  84  030; MANCON_3 ; ; S I 
MULATED ; FALSE ; YES ; CIS ; LPD_AG_CLASS ; $ 

UNIT ; DEFINE ; P2_LPD1_AIRSQUAD ; LF ; AIR_SQUADRON ; COMPANY ; P2_LPD1 
;AIRCON; ; SIMULATED; FALSE; YES ;USMC; MASS ; $ 

UNIT ; DEFINE ; P2_LPD1_AIRSUPPLY ; LF ; SUPPLY ; SQUADRON ; P2_LPD1 ; AIR 
CON ; ; S IMULATED ; FALSE ; NO ; $ 

ASSETS; UPDATE ;P2_LPD1_AIRSUPPLY; TROOPS; { 0150 ;HEALTHY; }$ 
ASSETS ; UPDATE ; P2_LPD1_AI RSUPPLY ; FUEL ; 1 0  0  0  0  0  0 ; $ 

ASSETS ; UPDATE ; P2_LPD1 ; FUEL ; 1 0  0  0  0  0  0 ; $ 

ASSETS ; UPDATE ; P2_LPD1_AIRSUPPLY ; RATIONS ; 5  0  0  0 ; $ 

ASSETS ; UPDATE ; P2_LPD1_AIRSUPPLY ; WATER ; 5  0  0  0  0 ; $ 

AIRFIELD ; DEFINE ; P2_LPD1 ; P2_LPD1 ; OPEN; ; P2_LPD1_AIRSUPPLY ; { 0 IP 
2_LPD1_AIRSQUAD ; } { 0  0 ; } $ 

a2c2_jp2_lhal 

UNIT ; DEFINE ; P2_LHA1 ; LF ; SHIP ; COMPANY; 52  SEQ2  60000; MANCON_3 ; ; S I 
MULATED ;  FALSE ;  YES ;  USN ;  LHA ;  $ 

UNIT; DEFINE;  P2_LHA1_AIRSQUAD;  LF ; AIR_SQUADRON ;  COMPANY;  P2_LHA1 
;  AIRCON ; ; SIMULATED ; FALSE ; YES ; USMC ; MASS ; $ 

UNIT ;  DEFINE ;  P2_LHA1_AIRSUPPLY ;  LF ;  SUPPLY ;  SQUADRON ;  P2_LHA1 ;  AIR 
CON ; ; S IMULATED ; FALSE ; NO ; $ 

ASSETS; UPDATE ;P2_LHA1_AIRSUPPLY; TROOPS; { 0150 ; HEALTHY; }$ 
ASSETS ; UPDATE ; P2_LHA1_AIRSUPPLY ; FUEL ; 1 0  0  0  0  0  0 ; $ 

ASSETS ; UPDATE ; P2_LHA1_AIRSUPPLY ; RATIONS ; 5  0  0  0 ; $ 

ASSETS ; UPDATE ; P2_LHA1_AI RSUPPLY ; WATER ; 5  0  0  0  0 ; $ 

AIRFIELD ; DEFINE ; P2_LHA1 ; P2_LHA1 ; OPEN; ; P2_LHA1_AIRSUPPLY ; { 0 IP 
2_LHA1_AI RSQUAD ; } { 0  0 ; } $ 

a2e2_p2_lnfl_p2_lhal_gouthbeach 
AIR_MISSION; DEFINE ; LHA_LAND_P2_INF1_SB ; MV- 
22 ; 1 ; P2_LHA1_AIRSQUAD ; P2_LHA1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 01SB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ;  DEFINE ;  LHA_LAND_P2_INF1_SB ;  LF ;  P2_LHA1 ;  USE_OF_AIRCRAFT 
; { 01P2_INF1 ; } SB;MV-22 ; 1; $ 

SERIAL ;  ASSOCIATE ;  LHA_LAND_P2_INF1_SB ;  LHA_LAND_P2_INF1_SB ;  $ 

a2e2_p2_inf l_p2_lhal_northbeach 

AI R_MI SSI ON ; DEFINE ; LHA_LAND_P2_INF1_NB ; MV- 

22 ; 1 ; P2_LHA1_AIRSQUAD ; P2_LHA1 ; ; ; ; STS ; 
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TAKE_OFF ; ; { 0 1NB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ;  DEFINE ;  LHA_LAND_P2_INF1_NB ;  LF ;  P2_LHA1 ; USE_OF_AIRCRAFT 
; { 01P2_INF1 ; }NB ; MV-22 ; 1 ; $ 

SERIAL ; ASSOCIATE ; LHA_LAND_P2_INF1_NB ; LHA_LAND_P2_INF1_NB ; $ 

a2c2_p2_infl_p2_lhal 

UNIT ; DEFINE ; P2_INF1 ; LF ; INFANTRY ; PLATOON; P2_LHA1 ; MANCON_3 ; ; SI 
MULATED ; FALSE ; YES ; USMC ; I FY_3 ; $ 

a2e2_p2_eng 

UNIT ; DEFINE ; P2_ENG ; LF ; ENGINEER ; COMPANY ; 52  SEQ2 11 0  8 1 ; MANCON_3 ; 
; SIMULATED ; FALSE ; YES ; USMC ; CMB_ENG ; $ 


a2c2_p2_ddg2 

UNIT; DEFINE ; P2_DDG2 ; LF; SHIP; COMPANY; 52SEQ455151 ;MANCON_3 ; ; SI 
MULATED ; FALSE ; YES ; USN ; BURKE_CLASS ; $ 


a2c2_p2_ddgl 

UNIT ; DEFINE ; P2_DDG1 ; LF ; SHI P ; COMPANY ; 5  2  SEQ4 89065; MANCON_3 ; ; SI 
MULATED ; FALSE ; YES ; USN ; BURKE_CLAS S ; $ 

a2c2_j>2^casl 

AIRCRAFT ;  DEFINE ;  FA- 18  ;  P1_CV1_AIR_SQUAD ;  0  0  02  ;  QUANTITY ;  2  ;  $ 

3l  2  c?  2l  _ 

UNITJdEFINE  ;  P2_AAAV1 ;  LF ;  AS SAULT_AMPH I B IAN ;  PLATOON;  P2_LHA1 ; MA 
NCON_3 ; ; S IMULATED ; FALSE ; YES ; USMC ; AAV ; $ 

a2c2_pl_vf4 

AIRCRAFT ; DEFINE ; F - 14 ; P1_CV1_AIR_SQUAD ; 0  0  0 1 ; QUANTITY ; 2 ; $ 


a2c2_pl_vf 3 

AIRCRAFT ; DEFINE ; F - 14 ; P1_CV1_AIR_SQUAD ; 0  0  0 1 ; QUANTITY ; 2 ; $ 
a2c2_pl_vf 2 

AIRCRAFT ; DEFINE ; F - 14 ; P1_CV1_AIR_SQUAD ; 0  0  0 1 ; QUANTITY ; 2 ; $ 
a2c2_pl_vf 1 

AIRCRAFT ; DEFINE ; F - 14 ; P1_CV1_AIR_SQUAD ; 0  0  0 1 ; QUANTITY ; 2 ; $ 
a2c2_pl_ffg2 

UNIT ; DEFINE ; P1_FFG2 ; LF ; SHI P ; COMPANY ; 5  2  SEP3 38949; MANCON_2 ; ; SI 
MULATED ; FALSE ; YES ; USN ; PERRY_CLASS ; $ 


a2e*2  pi  ffgl 

UNITTdEFINE ; P1_FFG1 ; LF ; SHI P ; COMPANY ; 5  2  SEQ4 21115; MANCON_2 ; ; SI 
MULATED ; FALSE ; YES ; USN ; PERRY_CLASS ; $ 

a2c2_pl_ddgl 
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UNIT ;  DEFINE ;  P1_DDG1 ;  LF ;  SHIP ;  COMPANY ;  52 SEP3  77967; MANCON  2  ;  ;  S I 
MULATED ; FALSE ; YES ; USN ; BURKE_CLASS ; $ 

a2c2_pl_cvl 

UNIT ; DEFINE ; P1_CV1 ; LF ; SHIP ; COMPANY ; 5 2 SEQ3 54 0 3 7 ; MANCON  2 ; ; S IM 
ULATED ; FALSE ; YES ; USN ; JFK_CLASS ; $ 

UNIT  ;  DEFINE ;  P1_CV1_AIRSUPPLY ;  LF ;  SUPPLY ;  COMPANY ;  P1_CV1 ;  AIRCON 
; ; S IMULATED ; FALSE ; YES ; USMC ; MAT_SUP ; $ 

UNIT;  DEFINE ;  P1_CV1_AIRSQUAD ;  LF ;  A I  R_SQUADRON ;  SQUADRON ;  PI  CV1  ; 
AIRCON ; ; S IMULATED ; FALSE ; YES ; USMC ; VMAAW ; $ 

AIRFIELD; DEFINE ;P1_CV1;P1_CV1; OPEN ;P1_CV1_AIRSUPPLY; PI  CV1  A 
IRSUPPLY; { 01P1_CV1_AIRSQUAD; } { 0  0 ; } $  ” 

ASSETS ; UPDATE ; P1_CV1_AIRSQUAD ; ASSET ; { 04MK- 84  - 
BOMB ; 5  0  0 ; OPERATIONAL ; ZUNI - RKT - 4 ; 

500;  OPERATIONAL ;  2  OMM-HE -  AC  ,-100000;  OPERATIONAL ;  MAVERI CK-TV- 
MSL ; 5  0  0 ; OPERATIONAL ; } $ 

ORD_LOAD ;  DEFINE ;  VF_AIR_ORD ;  LF ;  {  04MK-  84  -BOMB ;  8  ;  Q ;  MAVERICK- TV - 
MSL; 8 ; Q; ZUNI-RKT-4 ; 8 ; Q; 20MM-HE-AC; 1000 ;NONE; } $ 


a2  c  2_pl_cgl 

UNIT ; DEFINE ; P1_CG1 ; LF ; SHIP ; COMPANY ; 52SEQ34 0 014 ; MANCON  2 ; ; S IM 
ULATED ; FALSE ; YES ; USN ; BELKNAP_CLAS S ; $ 

a2c2_pl_casl 

AIRCRAFT ; DEFINE ;  FA- 18  ;  P1_CV1_AIRSQUAD ;  0002  ;  QUANTITY;  2  ;  $ 
a2c2_pQ_vf 4 

AIRCRAFT ; DEFINE ;  F- 14  ;  P1_CV1_AIRSQUAD;  0001 ; QUANTITY;  2  ;  $ 
a2c2_pQ_vf 3 

AIRCRAFT ; DEFINE ; F- 14 ; P1_CV1_AIRSQUAD ; 0  0  01 ; QUANTITY ; 2 ; $ 
a2c2__p0_vf  2 

AIRCRAFT ;  DEFINE ;  F- 14  ;  P1_CV1_AIRSQUAD ;  0 0 01 ; QUANTITY ;  2  ;  $ 

a2c2_pQ_vfl 

AIRCRAFT; DEFINE ;F- 14 ; P1_CV1_AIRSQUAD; 00 01; QUANTITY; 2 ; $ 

a2c2_p0_tarps 

AIRCRAFT ; DEF INE ; F - 1 4 ; P 1_CV1_AI RSQUAD ; 3  3  3  3 ; QUANT I TY ; 2 ; $ 

a2c2_pQ_launch_tarpg 
AIR_MI SS ION ; DEFINE ; TARPS ; F- 

14 ; 2 ; P1_CV1_AIRSQUAD; PI  CV1 ; ; ; ;RECON; { 04PHOTO; IR; 

SLAR ; VI SUAL ; }TAKE_OFF; ;T0152SEQ353 053 ; MEDIUM; ORBIT; } $ 


a2c2_pO_Gas2 

AIRCRAFT ;  DEFINE ;  FA- 18 ;  P1_CV1_AIR_SQUAD ;  0 0 02  ;  QUANTITY ;  2  ;  $ 
a2c2_p0_gagl 

AIRCRAFT; DEFINE; FA- 18 ;P1_CV1_AIR_SQUAD; 0002 ; QUANTITY; 2 ; $ 
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a2c2_laungh_p5_gagl 
AIR_MISSION; DEFINE ; P5_CAS1 ;  FA- 

18  ;  2  ;  P  1_CV1_AI RSQUAD ;  P1_CV1 ;  ;  ;  P5_ENG ;  CAS ;  CAS_ORD  ; 
; ; FALSE ; TAKE_OFF ; ; { 0152SEQ306046 /MEDIUM /ORBIT; }$ 

a2c2_launch_p4_cas2 
AIR_MISSION ; DEFINE ; P4_CAS2 ; FA- 

18  ;  2  ;  P1_CV1_AI RSQUAD ; P1_CV1 ; ; ; P5_ENG ; CAS ; CAS_ORD ; 
; ; FALSE ;TAKE_OFF; ;{ 0152SEP357997 /MEDIUM; ORBIT; } $ 

a2e2_launch_p4_Gagl 
AIR_MISSION ; DEFINE ; P4_CAS1 ; FA- 

18  ;  2  ;  P1_CV1_AIRSQUAD ;  P1_CV1 ;  ;  ;  P5_ENG;  CAS ;  CAS_ORD  ; 
;  ;  FALSE ; TAKE_OFF ; ; { 0152SEQ321022 /MEDIUM /ORBIT; } $ 

a2c2_larnich_p3_eagl 
AIR_MISSION; DEFINE ; P3_CAS1 ; FA- 

18  ;  2  ;  P1_CV1_AI RSQUAD ;  P1_CV1 ;  ;  ;  P5_ENG ;  CAS ;  CAS_ORD  ; 
; / FALSE ;TAKE_OFF; ; { 0152SEQ371072 /MEDIUM /ORB IT; } $ 

a2c2_launch_pl_casl 

AIR_MISSION; DEFINE ; P1_CAS1 ;  FA- 

18  ;  2  ;  P1_CV1_AIRSQUAD ;  P1_CV1 ;  /  /  P5_ENG ;  CAS ;  CAS_ORD  ; 
; ; FALSE ;TAKE_OFF; ; { 0152SEQ334058 /MEDIUM; ORBIT; } $ 


a2  c2_crea t e_t er rain 

CE ; CONSTRUCT ; RD1 ;  ;  ;  IMPROVED_SURFACE ; ROAD ; ASPHLT -2- 
LANE; { 1352SEQ325127 ; 

52SEQ324121 ; 52SEQ317117 ; 52SEQ309120 ; 52SEQ305117 ; 52SEQ303114 ; 
52SEQ292105 ; 52SEQ269104 ; 52SEQ263102 ; 52SEQ255087 ; 52SEQ222069; 
52SEQ219066 ; 52SEQ210026 / } $ 

CE ;  CONSTRUCT ;  RD2  ;  ;  ;  IMPROVED_SURFACE  /  ROAD  /  ASPHLT-  2  -LANE  ; 
{1752SEQ237077; 52SEQ238073 /52SEQ234063 /52SEQ237052 /52SEQ2340 
44;  " 

52SEQ23603  9  ;  52SEQ232026  /  52SEQ224024  ;  52SEQ219018  ;  52SEQ21.4017  ; 
52SEQ213014 ; 52SEQ202001; 52SEP194994 ; 52SEP190994 ; 52SEQ183004 ; 
52SEQ167000 ; 52SEP154985 ; } $ 

CE; CONSTRUCT ;RD3 ; ; ; IMPROVED_SURFACE; ROAD /ASPHLT- 2- 
LANE ; { 1552SEQ235161 ; 52SEQ234158 ; 52SEQ235156 ; 52SEQ233155 ; 
52SEQ235150 ; 52SEQ234147; 52SEQ240140 ; 52SEQ239126 ; 52SEQ235119; 
52SEQ235109 ; 52SEQ230101 ; 52SEQ228100 ; 52SEQ227090 ; 52SEQ222080 ; 
52SEQ221079 ; } $ 

CE  /  CONSTRUCT ;  RD4  ;  ;  ;  IMPROVED_SURFACE ;  ROAD ;  AS  PHLT  -  2  -  LANE  ; 

{ 0852SEQ128118 ; 52SEQ133118 ; 52SEQ145110 ; 52SEQ145107 ; 52SEQ1490 
92  ; 

52SEQ172079 ; 52SEQ188084 ; 52SEQ202076  ;  } $ 

CE ; CONSTRUCT ; RD5 ; / ; IMPROVED_SURFACE / ROAD ; ASPHLT - 2 - LANE ; 

{ 0352SEQ221077 ; 52SEQ219066 ; 52SEQ204076 ; }$ 
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CE ;  CREATE ;  HI  LL ;  NATURAL_TERRAIN ;  MOUNTAIN ;  MOUNTAIN  ;{0652SEQ284 
126 ; 52SEQ276122 ; 52SEQ275115 ; 52SEQ284111 ; 52SEQ294116 ; 52SEQ2  92 
125;}$ 

CE ; CREATE ; PORT ; STRUCTURE ; PORT- 
FACILITY; 52SEQ315116 ; 15 ; 40 ; 100 ; $ 

CE ; CREATE ; RVR1 ; NATURAL_TERRAIN ; RIVER ; RIVER ; 1 0  0 ; { 0  3  5  2 SEQ24 2  09 
0 ; 52SEQ223076 ; 52SEQ213087 ; } $ 

CE ; CREATE ; RVR2 ; NATURAL_TERRAIN ; RIVER ; RIVER ; 1 0  0 ; { 0  2  52  SEQ2 1308 
7 ; 52SEQ196068 ; } $ 

CE ; CONSTRUCT ; BRIDGE1 ; ; ; IMPROVED_SURFACE ; BRIDGE ; CONCRETE - 
BRIDGE-A; 52SEQ203076 ;RVR1 ; $ 

CE ; CONSTRUCT ; BRIDGE2 ; ; ; IMPROVED_SURFACE ; BRIDGE ; CONCRETE - 
BRIDGE -A; 52SEQ221078 ;RVR2 ; $ 

a2c2_create_intel_blue 

UNIT; DEFINE; INTEL ;LF; RECONNAISSANCE; PLATOON; 52SEQ205092 ; INT_ 
CON_l ; ; S IMULATED ; TRUE ; YES ; USMC ; D I V_RECON ; $ 

ASSETS; UPDATE; INTEL; ASSET; { 01SENSOR-1 ; 16  OPERATIONAL ; }$ 

a2c;2  gag  ord 

ORD_LOAD7 DEFINE ;  CAS_ORD ;  LF;  {  02MK-84  -LGB ;  32  ;Q;  MAVER I CK - TV - 
MSL; 32 ;Q; } $ 

ASSETS ; UPDATE ; P1_CV1_AIRSQUAD ; ASSET ; { 03MAVERICK-TV- 
MSL; 1000; OPERATIONAL; 

NAPALM - BOMB ; 1 0  0  0 ; OPERAT I ONAL ; MK- 8  4 - LGB ; 1 0  0  0 ; OPERAT I ONAL ; } $ 
a2c2_beaches_and_LZs 

BEACH ; DEFINE ; SOUTH_BCH ; LF ; 5  2  SEQ2 3  0  0  0  6 ; 5  2  SEQ24 5  0  2  0 ; ; ; 5  2  SEQ2  3  2 
004 ; 52SEQ249016 ; 52SEQ237015 ; { 0352SEQ252014 ; 52SEQ236002 ; 52SEQ 
252004;};;;$ 

BEACH ; DEFINE ; NORTH_BCH ; LF ; 52SEQ2 6  8  0  6  5 ; 5  2  SEQ2 8  9  0  74 ; ; ; 52 SEQ2 6  9 
061; 52SEQ292071 ; 52SEQ279073 ; { 0352SEQ275060 ; 52SEQ293066 ; 52SEQ 
289054;};;;$ 

CHECKPOINT ; DEFINE ; NB ; 52SEQ276  071 ; LF ; YES ; $ 

CHECKPOINT ; DEFINE ; SB ; 5  2  SEQ2 3  5  0 1 2 ; LF ; YES ; $ 

a2c2_airfield 

UNIT ;  DEFINE ;  P2_LHA1_AIRSUPPLY ;  LF ;  SUPPLY ;  SQUADRON ;  P2_LHA1 ;  AIR 
CON ; ; S IMULATED ; FALSE ; NO ; $ 

ASSETS ; UPDATE ; P2_LHA1_AIRSUPPLY ; TROOPS ; { 0 1 5  0 ; HEALTHY ; } $ 
ASSETS ; UPDATE ; P2_LHA1_AIRSUPPLY ; FUEL ; 1 0  0  0  0  0  0 ; $ 

ASSETS ; UPDATE ; P2_LHA1_AIRSUPPLY ; RATIONS ; 5  0  0  0 ; $ 

ASSETS ; UPDATE ; P2_LHA1_AIRSUPPLY ; WATER ; 5  0  0  0  0 ; $ 

AIRFIELD ; DEFINE ; P2_LHA1 ; P2_LHA1 ; OPEN ; ; P2_LHA1_AIRSUPPLY ; { 0 IP 
2_LHA1_AIRSQUAD ; } { 0  0 ;  } $ 

Master  Batch  Files 

A2C2A0 

a2c2_create_terrain 
a2c2  beaches  and  LZs 
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a2  c  2_r ed_de  f  ens  e 

a2c2_trucks_create 

a2c2_run_t rucks 

a2c2_pl_cgl 

a2c2_pl_cvl 

a2c2_pl_ddgl 

a2c2_pl_ffgl 

a2c2_pl_f fg2 

a2c2_p2_lhal 

a2c2_p2_lpdl 

a2  c2_p2_mv2  2_p2_lhal 

a2  c2_p3_mv2  2  a_p2_lpdl 

a2c2_p3_mv22b_p2_lpdl 

a2c2_p3_aaavl_on_p2_lhal 

a2c2_p3_aaav2_on_p2_lhal 

a2c2_p3_aaav3_on_p2_lpdl 

a2c2_p0_tarps 

a2c2_p0_vf 1 

a2c2_p0_vf2 

a2c2_p0_vf3 

a2c2_p0_vf 4 

a2c2_pl_casl 

a2c2_p2_inf  ljp2_lhal 

a2c2_p2_medl_lpdl 

a2c2_p2_med2_lhal 

a2c2_p2_med3_lhal 

a2c2_p3_inf l_p2_lpdl 

a2c2_p3_inf2jp2_lpdl 

a2c2_p3_inf3_p2_lpdl 

a2c2_p3_inf4_p2_lhal 

a2c2_p3_eng 

a2c2_p4_casl 

a2c2_p4_cas2 

a2c2_p5_casl 

a2c2_p5_eng 

a2c2_p5_sof 

a2  c2_p4_ahl  -  l_jp2_lpdl 

a2c2  cas  ord 
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APPENDIX  B.  UNIT  LISTINGS 
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APPENDIX  C.  ARCHITECTURES 


The  following  pages  contain  pictures  of  the 
organization  structure  of  the  various  architectures  used  in 
A2C2  experiment  number  3 .  [Ref  1]  . 
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A1 


Figure  20.  Architecture  A1 . 


A2 


Figure  21.  Architecture  A2 . 


AG’ 


“ITALICIZED  PLATFORMS  ARE  STATIONARY 


Figure  22.  Architecture  AO  prime. 
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AO’  (Post) 


Figure  23.  Architecture  AO  prime  Post -Trigger . 
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APPENDIX  D.  THE  A2C2  SCENARIO 

The  document  on  the  following  pages  is  the  fictitious 
operational  order  that  was  used  for  A2C2  experiment  number 
three.  [Ref.  1] . 


IMMEDIATE 


FROM:  USCENCMED  NAPLES  IT 

JIT  1000 

TO:  CJCS  WASHINGTON  DC 

USCINCCENT  MACDILL  AFB  FL 
USCINCLANT  NORFOLK  VA 
USCINCEUR  VAIHINGEN  GE 
CINCFOR  FT  MCPHERSON  GA 
USCINCPAC  HONOLULU  HI 
USCINCTRANS  SCOTT  AFB  IL 
USCINCSTRAT  OFFUTT  AFB  NE 
COMMARFORPAC  HONOLULU  HI 
CINCPACFLT  HONOLULU  HI 

INFO:  WHITEHOUSE  SITUATION  ROOM  WASHINGTON  DC 

SECSTATE  WASHINGTON  DC 
SECDEF  WASHINGTON  DC 
CSA  WASHINGTON  DC 
CMC  WASHINGTON  DC 
CNO  WASHINGTON  DC 

DIS1R:  CINC/DCINC/CCJ1/CCJ2/CCJ3/CCJ4/CCJ5/CCJ6 

FOR  OFFICIAL  USE  ONLY 
OPER/REDNOSE// 

MSGID/ORDER/USCINCCENT// 

AMPN/SPECIAL  HANDLING  INSTRUCTIONS 
REF/A/ORDER/CJCS/OI 1742Z  NOV  97// 

REF/B/ORDER/CJCS/041 142Z  NOV  97// 

NARR/JT  STRAT  CAP  PLN  (FY  97),  CJCS  ALERT  ORDER// 
ORDTYP/OPORD/USCINCCENT  12-97// 

MAP/10 15/TUNSIA// 

MAP/1020/ALGERIA// 

NARR/SCALE  1:100,000// 

TIMEZONE/Z// 
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HEADING/TASK  ORGANIZATION// 


5UNIT 

AJNITDES 

/UNITLOC 

/CMNTS 

/USCINCLANT 

/NORFOLK  VA 

/USCINCEUR 

/VAJHINGEN  GE 

/CINCFOR 

/FT  MCPHERSON  GA 

/USCINCPAC 

/HONOLULU  HI 

/USCINCTRANS 

/SCOTT  AFB  EL 

/2  TAC  ARLFT  SQ 
/6KC-10 

/USCINCSTRAT 

/OFFUTT  AFBNE 

/2  RC-135 

/COMMARFORPAC 

/HONOLULU  HI 

/I  MEB 

/CINCPACFLT 

/HQ  USMEDCOM  FWD 

/HQ  USMEDAF  (MINUS) 

/2  E-3A  (AWACS) 

/HQ  USNAVMED  (MINUS) 
/SUPPORTING  FORCES 
/COMSUPNAVFOR 
/CTG  60.1  (CVBG) 

/ARG  55.2 
/ 1  MEB 
/MPS// 

/HONOLULU  HI 

/(JTF  1000) 

GENTEXT/SITUATION 

1.  (FOUO)  Country  Orange  has  attacked  the  friendly  nation  of  Country  Green,  an  U.S.  ally.  Attacking 
forces  have  succeeded  in  seizing  Country  Green  port  of  Eastport.  Country  Green  government  has 
requested  U.S.  assistance  in  taking  back  port  of  Eastport  and  driving  Country  Orange  forces  from  Country 
Green. 


A.  (FOUO)  ENEMY  FORCES 

(1)  (FOUO)  See  current  SITREP  and  DIN.  The  port  of  Eastport  is  protected  by 
obstructions,  mines,  obstacles,  and  the  presence  of  hidden  enemy  among  the  port  facility  buildings.  Two 
beaches  approx.  5  miles  south  of  the  port  may  be  suitable  for  amphibious  assault.  Northernmost  beach 
(designated  “North  Beach”)  has  road  leading  to  the  port.  Southernmost  beach  (designated  “South  Beach”) 
has  a  road  leading  to  the  airfield.  Waterborne  approaches  to  the  beaches  are  possibly  mined. 

Commanding  terrain  to  north  of  Red  Beach  believed  occupied  by  enemy  Heavy  Mortar  Platoon  with  a 
platoon  of  Infantry  for  security.  This  terrain  dominates  both  North  Beach  and  the  port.  Seizure  and 
retention  of  this  dominant  terrain  should  be  considered  essential  for  successful  attack  on  Red  Beach  and 
port. 


(2)  (FOUO)  There  are  two  Orange  bases  inland.  Intel  reports  indicate  that  mobile 
missile  forces  occupy  one  of  the  bases,  but  it  is  not  known  which.  Each  base  is  connected  by  road  to  the 
port-Red  Beach  road  and  the  road  to  each  base  has  a  bridge.  Missile  units  from  either  bas  will  have  to 
travel  down  the  road  and  cross  the  bridge  to  bring  U.S.  forces  to  within  effective  range.  Orange  tactics 
and  the  current  situation  dictate  that  Orange  send  an  advanced  force  to  secure  the  bridge  before  sending 
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any  Transporter  Erector  Launchers  (TELs)  across.  To  prevent  this,  a  Special  Operations  Force  (SOF)  has 
been  inserted  at  an  observation  post  (OP)  near  the  bridges.  Their  mission  is  to  determine  which  base  the 
missile  force  occupies  and  blow  up  the  bridge  leading  to  that  base.  There  is  a  significant  amount  of 
neutral  commercial  traffic  on  the  connecting  roads,  and  while  the  SOF  sensors  can  detect  traffic  on  the  far 
side  of  the  bridges,  they  cannot  discriminate  between  neutral  commercial  traffic  and  a  hostile  advance 
force.  Air  (TARPS)  or  space  based  (SAT)  sensors  will  have  to  be  used  to  establish  positive  hostile 
identification  (PHID). 

(3)  (FOUO)  Believed  to  be  at  the  port,  but  hidden  from  view,  is  company-sized 
armored  counterattack  force  that  could  move  toward  North  Beach  in  response  to  any  amphibious  assault. 
Similar  counterattack  force  may  exist  at  airfield,  which  is  located  about  5  miles  inland  from  the  South 
Beach.  These  counterattack  forces  could  inflict  serious  damage  if  not  interdicted  before  they  reach  either 
beach.  Off-road  terrain  between  beach,  port,  airfield,  and  commanding  terrain  is  swampy  and 
treacherous;  and  is  unsuitable  for  travel.  Thus,  all  ground  travel,  with  the  exception  of  the  SOF  who  are 
equipped  with  advanced  All-Terrain  Vehicles  (ATVs),  must  be  on  the  roads.  It  is  believed  that  one  or 
both  of  the  roads,  which  connect  the  port  and  airfield  to  the  beaches,  will  be  mined.  Locations  of  any 
minefields  are  currently  unknown.  Port,  airfield,  both  roads,  both  beaches,  and  commanding  terrain  are 
located  within  range  of  artillery  strong  points,  which  must  be  suppressed.  Northernmost  strong-point  can 
fire  on  North  Beach  and  port.  Southernmost  strongpoint  can  fire  on  both  South  Beach  and  airfield. 
Artillery  pieces  at  both  strong  points  are  housed  in  reinforced  concrete  bunkers,  with  ammunition  stored 
in  deep  underground  bunkers.  It  is  unlikely  that  even  concentrated  air  attacks  will  completely  disable  the 
artillery  strong  points.  Enemy  can  be  expected  to  wheel  out  artillery  pieces  (from  8  to  24  at  a  time),  set 
up,  sight  in,  and  fire  in  under  2.5  minutes.  If  friendly  forces  can  get  effective  NSFS  on  target  in  less  than 
2.5  minutes,  the  enemy  will  probably  wheel  their  artillery  pieces  back  into  bunkers  and  wait  until  another 
time. 


(4)  (FOUO)  Enemy  Surface-to-Air  Missile  (SAM)  sites  and  decoys  have  been  erected 
around  the  port  and  airfield.  The  SAM  sites  must  be  identified  and  destroyed  before  air  support  or  helo- 
bome  forces  can  safely  be  used  for  the  attack  on  the  port.  To  minimize  collateral  damage,  the  sites  must 
be  hit  with  guided  munitions. 


(5)  (FOUO)  Enemy  also  has  several  Frog  Missile  Launchers  (SCUD-like)  capable  of 
carrying  chemical  munitions.  Frogs  are  believed  to  be  hidden  in  the  vicinity  of  both  artillery  strongpoints. 
They  can  emerge  from  covered  positions,  prepare  warheads,  and  fire  missiles  within  4  minutes.  Past 
experience  has  shown  that  Frog  crews  are  more  stalwart  than  artillery  crews.  They  will  continue  to 
prepare  and  launch  their  missiles  even  if  they  are  being  suppressed  by  NSFS  or  artillery. 


(6)  (FOUO)  Submarine  threat  to  U.S.  Naval  forces  is  considerable.  Enemy  Alfa-Class 
submarines  are  known  to  be  in  the  area.  To  protect  the  fleet,  these  submarines  must  be  detected  and 
destroyed. 


(7)  (FOUO)  Enemy  possesses  HIND  Helicopters,  and  has  demonstrated  the  capability 
to  launch  anti-ship  missiles  from  its  helicopters.  The  only  significant  capability  the  ARG  or  CVBG 
possesses  against  these  helicopters  is  one  Stinger  Platoon. 

(8)  (FOUO)  The  enemy  has  significant  air  strike  capability,  and  can  launch  anti-ship 
missiles  from  most  of  its  strike  aircraft. 
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(9)  (FOUO)  The  enemy’s  Maritime  Special  Forces  also  possess  numerous  fast  patrol 
boats  (PBs),  that  can  either  fire  very  potent  torpedoes,  be  loaded  with  explosives  for  suicide  missions,  or 
carry  troops  and  supplies  to  reinforce  Orange  forces.  These  can  be  engaged  and  destroyed  by  the  CG, 
DDGs,  FFGs,  fighters,  and  Cobras.  But,  they  have  been  camouflaged  to  resemble  a  type  of  commercial 
coastal  craft  common  in  the  area,  and  they  are  known  to  travel  at  the  same  speed  as  coastal  traffic  to  avoid 
giving  away  their  identity.  These  PBs  must  be  identified  by  either  SAT,  TARPS,  or  very  close  inspection 
by  friendly  surface  platforms  before  they  can  be  engaged.  There  are  two  popular  coastal  trade  routes 
between  the  mainland  and  a  large  island  to  the  east.  One  route  goes  to  the  north  of  Green  and  passes 
close  to  a  small  inlet  which  could  support  offloading  of  troops  and  supplies  to  Orange  forces  occupying 
the  port  area.  The  other  route  passes  south  along  the  east  coast  and  passes  close  to  a  beach  south  of  the 
airfield,  which  could  support  offloading  of  troops  and  supplies  to  reinforce  Orange  forces  around  the 
airfield.  Maritime  traffic  along  these  routes,  and  in  the  region  overall,  must  be  positively  identified  to 
ensure  the  destruction  of  all  hostile  boats  while  avoiding  attacking  neutral  shipping. 

(10)  (FOUO)  There  is  also  a  Silkworm  threat  along  the  coastline.  These  Silkworm 
missiles  were  placed  in  residential  neighborhoods  by  the  enemy  because  they  knew  U.S.  planners  would 
be  reluctant  to  target  residential  areas.  Accordingly,  if  U.S.  forces  want  to  target  a  Silkworm  launcher, 
they  must  first  get  positive  confirmation  of  its  presence,  using  reconnaissance  assets  (TARPS,  SOF, 
Satellite).  Any  strike  must  use  precision  guided  munitions  (CAS). 

B.  (FOUO)  FRIENDLY  FORCES.  JTF  will  be  comprised  primarily  of  assets  organic  to 
Mediterranean  Command  (MEDCOM).  A  theater-level  JFACC  and  other  friendly  forces  are  operating 
against  the  enemy  in  Country  Green,  but  not  in  concert  with  the  JTF.  This  forces  the  requirement  to 
identify  contacts  prior  to  attacking  to  ensure  friendly  and  neutral  forces  are  not  destroyed. 

(1)  (FOUO)  JTF  will  consist  of  one  Aircraft  Carrier  Battle  Group  (CVBG),  and  a 
Amphibious  Ready  Group  (ARG)  with  embarked  Marines.  The  ARG  will  be  composed  of  1  LHA  and  1 
LPD.  CVBG  will  be  composed  of  1  CV,  1  AEGIS  cruiser,  2  DDGs,  and  2  FFGs. 


(2)  (FOUO)  The  CVBG  and  ARG  aircraft  available  to  support  the  JTF  are  4  sections  of 

F-14s,  4  sections  of  F/A-18s,  and  1  TARPS  equipped  F-14.  The  F/A-18s  from  the  CV 

are  equipped  with  Laser  Guided  Bombs  (LGBs)  and  can  attack  Frog  missile  sites  or  confirmed  Silkworm 
sites,  or  they  can  be  used  to  provide  Close  Air  Support  (CAS)  for  friendly  ground  units.  The  F-14s  can  be 
used  for  Anti-Air  Warfare  (AAW)  and  for  Combat  Air  Patrol  (CAP).  The  F-14  TARPS  can  be  used  for 
reconnaissance  missions  only. 

(3)  (FOUO)  In  addition  to  TARPS,  the  JTF  has  access  to  an  imagery  satellite  (SAT 
platform)  which  can  provide  continuous  wide-angle  “detection”  coverage  throughout  the  objective  area. 
High-resolution  “identification”  coverage  is  available  for  a  small  (movable)  area. 

(3)  (FOUO)  Two  DDGs  will  be  in  position  to  provide  NSFS.  Small  Minesweeping 
Craft  (SMCs)  are  attached  to  the  ARG  to  clear  sea  mines  if  detected. 

(4)  (FOUO)  The  Marine  amphibious  forces  are  embarked  on  the  ARG.  The  ARG  is 
composed  of  three  Advanced  Amphibious  Assault  Vehicle  (AAAV)-mounted  rifle  companies,  three  V-22 
Osprey-mounted  helibome  rifle  companies,  4  sections  of  AH-1W  SeaCobras  (indivisible),  two 
mineclearing  boats  (SMCs),  two  engineer  platoons,  and  three  of  MEDEVAC  helicopters.  Engineers  must 
be  used  to  breach  any  minefields  encountered  by  JTF  ground  forces.  Cobras  are  the  only  JTF  assets  which 
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by  themselves  are  effective  against  armored  formations.  Two  Stinger  Detatchments  will  provide  a  close-in 
anti-air  capability. 


(5)  (FOUO)  Ground  forces  have  unmanned  aerial  vehicles  (UAVs)  flying  in  support 
for  the  duration  of  the  operation.  Continuous  live  feed  will  be  fed  to  the  Common  Operational  Picture 
(COP)  available  to  all  friendly  forces. 

GENTEXT/MISSION 

2.  (FOUO)  On  order,  JTF  1  ground  forces  will  seize  and  defend  Country  Green  Port  of  Eastport,  to  allow 
introduction  of  follow  on  forces  in  support  of  Country  Green  government  troops.  Sea-based  forces  will 
support  amphibious  assault  with  CAS,  naval  gunfire,  and  air  defense  assets  to  defend  the  CVBG  and  ARG 
from  air,  surface,  and  subsurface  threats.// 

GENTEXT/EXECUTION/ 

3.  (FOUO)  CONCEPT  OF  OPERATIONS 

A.  GROUND.  The  SOF  will  be  inserted  prior  to  the  commencement  of  the  amphibious 
landings.  One  AAAV-mounted  rifle  company  will  land  on  each  beach  near-simultaneously.  As  a 
prerequisite  to  this,  one  helibome  rifle  company  will  secure  the  commanding  terrain  overlooking  Red 
Beach  and  the  port  in  a  coordinated  attack.  Once  BOTH  beaches  and  commanding  terrain  are  secure,  the 
two  AAAV-mounted  companies  will  proceed  on  foot  down  the  roads  from  their  respective  beaches, 
clearing  minefields  with  engineer  platoons,  killing  counterattack  forces  with  Cobras,  and  conducting 
MEDEVACS  as  necessary.  The  roads  must  be  cleared  prior  to  attacking  the  port  or  airfield.  The  SOF 
should  conduct  surveillance  to  locate  the  enemy  missile  force  and  destroy  the  applicable  bridge,  then 
proceed  as  directed  to  assist  in  assaults  on  the  port  and  airfield.  The  UAVs  will  keep  the  artillery  strong 
points  and  the  suspected  FROG  sites  under  constant  surveillance,  so  that  NSFS  or  CAS  assets  can  be 
brought  to  bear  immediately  if  they  are  needed.  Once  the  roads  have  been  cleared,  the  AAAV-mounted 
companies  will  take  the  port  and  airfield.  A  helibome  company  will  assist  the  company  attacking  the 
airfield.  It  is  important  that  once  the  AAAV-mounted  companies  land  on  the  beach,  the  airfield  and  port 
be  taken  as  quickly  as  possible,  before  the  enemy  has  a  chance  to  organize  his  defense  and  send 
reinforcements.  It  is  desired  that  final  assaults  on  the  airfield  and  port  occur  simultaneously,  in  order  to 
present  the  enemy  commander  with  the  most  confusing  environment  possible.  However,  if  one  attack 
must  occur  before  the  other,  the  airfield  has  the  priority.  If  the  airfield  attack  is  held  up  for  any  reason, 
the  port  attack  should  wait  to  retain  the  synergism  of  concurrent  attacks.  If  the  port  attack  is  held  up,  the 
airfield  attack  should  go  forward. 

B.  MARITIME.  Due  to  hydrographic  limitations,  the  ARG  and  the  CVBG  will  have  to  be 
significantly  separated  during  the  operation,  enough  to  preclude  them  from  being  under  a  Joint  Air 
Defense  umbrella  provided  by  the  AEGIS  Cruiser.  Thus,  the  AEGIS  Cruiser  will  remain  with  the  CVBG, 
but  will  position  itself  so  that  it  can  rapidly  move  from  the  CVBG  to  the  ARG  if  that  becomes  necessary. 
Additionally,  the  two  DDGs  are  inshore,  providing  NSFS  support,  while  the  FFGs  are  primary  ASW 
platforms  for  the  CVBG.  The  FFGs  performing  ASW  will,  like  the  AEGIS  Cruiser,  position  themselves 
so  that  they  can  quickly  move  to  support  the  ARGs  if  that  is  necessary.  The  frigates,  AEGIS  cruiser,  and 
destroyers  can  attack  or  be  attacked  by  the  enemy  patrol  boats.  The  ARGs  will  launch  the  Marines  for  the 
initial  assault  on  Ted  and  Blue  Beaches  at  the  commencement  of  the  operation,  and  will  launch  the 
minesweeping  boats,  SeaCobras,  MEDEVAC  helos,  the  air  assault  for  the  attack  on  the  airfield,  etc.  when 
called  to  do  so.  The  destroyers  will  provide  NSFS  to  suppress  enemy  artillery  ashore  and  for  other 
missions  when  requested  to  do  so.  If  a  suspected  Silkworm  launcher  is  detected,  TARPS,  SOF,  or 
Satellite  must  identify  it  before  it  can  be  destroyed.  Silkworm  and  SAM  sites  require  a  coordinated  laser 
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designation  in  order  to  achieve  a  perfect  attack.  A  Silkworm  launcher  detected  at  the  northernmost  site 
threatens  the  CVBG,  and  one  at  the  southermost  site  threatens  the  ARGs.  SAM  sites  protect  the  port  and 
airfield. 

4.  (FOUO)  FIRST  TASK  ASSIGNMENT  CLF.  On  order  of  the  JTF  1,  land  two  AAAV-mounted 
companie  on  Red  Beach  and  Blue  Beach  concurrently.  Simultaneously  seize  commanding  terrain  to  the 
north  of  Red  Beach  with  one  helibome  company.  Once  the  beach  and  commanding  terrain  are  secure, 
attack  along  the  roads  from  the  beaches  to  the  port  and  airfield  with  the  AAAV-mounted  companies, 
clearing  minefields  with  the  attached  Engineer  Platoon,  killing  counterattack  forces  with  assigned  Cobras 
and  conducting  MEDEVACS  as  necessary.  Once  the  roads  have  been  cleared,  conduct  a  simultaneous 
coordinated  attack  on  the  port  and  airfield  with  your  AAAV-mounted  companies  and  your  helibome 
companies. 

(FOUO)  SECOND  TASK  ASSIGNMENT  CVBG.  Support  the  CLF  and  subordinates  by  launching 
requested  assets  and  providing  fighter  support. 

7.  (FOUO)  THIRD  TASK  ASSIGNMENT  ARG.  On  order  of  JTF  1,  ARG  will  initially  clear  mines 
from  the  beaches  with  the  Minesweeping  Boats.  ARG  will  launch  3  Companies  of  Marines  for  the  initial 
assault  on  Red  and  Blue  Beaches  and  the  hill.  The  ARG  will  launch  the  Cobras,  MEDEVAC  helos,  the 
helibome  company  for  the  attack  on  the  airfield.  ARG  will  also,  with  NSFS  DDGs,  suppress  artillery 
positions. 

8.  (FOUO)  COORDINATING  INSTRUCTIONS. 

A.  (FOUO)  This  order  effective  for  planning  upon  receipt  and  execution  on  order. 

B.  (FOUO)  Dirlauth  for  planning  and  operations  with  Info  CJCS  and  CINCMED. 

C.  (FOUO)  ROE  will  be  per  CINCMED  OPLAN  1234. 

D.  (FOUO)  Friendly  forces  will  have  a  UAV  (launched  from  the  ARG)  airborne  for  the  duration 
of  the  operation.  The  UAV’s  will  keep  the  artillery  strong-points  and  the  suspected  FROG  sites  under 
constant  surveillance,  so  that  NSFS  or  CAS  assets  can  be  brought  to  bear  immediately  if  needed. 

E.  (FOUO)  If  the  airfield  attack  is  held  up  for  any  reason,  the  port  attack  will  be  delayed  to 
retain  the  synergism  of  concurrent  attacks.  If  the  port  attack  is  held  up,  file  airfield  attack  will  go  forward. 

F.  (FOUO)  The  attack  on  the  airfield  has  priority,  because  enemy  buildup/sustainment  of  forces 
can  be  most  quickly  and  effectively  achieved  through  air  transport. 


// 

GENTEXT/ADMIN  AND  LOG/ 

7.  (FOUO)  Per  CINCMED  OPLAN  1234,  as  amended  herein.// 
GENTEXT/COMMAND  AND  SIGNAL/ 

8.  (FOUO)  USCINCMED  is  supported  CINC. 
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9.  (FOUO)  CJTF  1  is  on-the-scene  Commander  and  will  exercise  OPCON  of  advance  forces  until  HQ 
USCINCMED  FWD  is  activated. 

10.  (FOUO)  Command  relationships  as  outlined  in  Annex  J,  CINCMED  OPLAN  1234. 

1 1 .  (FOUO)  Communications  guidance  as  outlines  in  Annex  K,  CINCMED  OPLAN  1234  as  amended 
herein.// 

AKNLDG/Y// 

DECL/OADR// 
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APPENDIX  E.  CHANGES  MADE  TO  THE  PARAMETRIC  DATABASE 

The  following  changes  were  made  to  the  parametric 
database.  The  parametric  database  can  be  launched  from  a 
standard  MDS  login  (see  Appendix  F)  by  right  click  the  mouse 
and  selecting  APPLICATIONS  ->  PARA  EDITOR.  For  more 
information  on  editing  the  parametric  database,  contact  Mac 
Garrabrants,  Project  Manager,  Modeling  and  Simulation, 
VisiCom  Labs.  [Ref.  3]. 

A.  LAND  MINES 

Only  the  lowest  density  of  mines  were  used. 
Additionally,  the  removal  settings  were  changed  to  1  minute 
per  man  per  square  meter  of  mines,  and  a  maximum  work  crew 
of  1000.  These  changes  were  made  to  facilitate  mine  removal 
by  the  engineers.  At  the  default  settings,  removing  a  small 
minefield  can  take  hours.  By  increasing  the  personnel  in  a 
standard  engineering  squadron,  the  removal  time  be  lowered 
even  more  to  meet  the  needs  of  the  A2C2  scenario. 

B.  BRIDGES 

Like  land  lines  mines  the  removal  time  was  set  to  1 
minute  per  man  per  square  meter.  The  min  work  crew  was  set 
to  20,  and  the  max  crew  was  set  to  200.  The  numbers  can  be 
varied.  The  more  units  working  on  the  bridge  removal  in  a 
coordinated  effort,  the  more  rapidly  the  bridge  can  be 
removed . 
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C .  DEFAULT  TERRAIN 

The  default  terrain  settings  were  set  to  allow  all 
units  to  move  at  the  fastest  speed  possible.  These 
settings,  in  conjunction  with  the  move  and  speed  override 
commands  will  allow  units  to  move  in  a  predictable  manner 
over  any  terrain. 

D.  SHIP  MAXIMUM  DETECTION  RANGE 

In  order  to  detect  sea  mines,  the  maximum  detection 
range  on  ship  used  in  this  experiment  was  set  to  8000 
meters.  This  setting  is  only  useful  if  the  sea  mines 
capability  is  implemented  in  the  MTWS  version  of  the 
scenario.  A  sea  mine  removal  technique  was  not  developed 
because  of  time  constraints. 
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APPENDIX  F.  STARTING  MTWS 


The  following  are  startup  procedures  for  MTWS.  A 
system  administrator  who  is  knowledgeable  about  HP  UNIX 
operating  systems  should  be  available  for  any  operating 
system  specific  issues. 

A.  BEFORE  LOADING  MTWS 

All  of  the  computer  workstation  on  the  MTWS  network 
that  are  to  be  used  in  an  exercise  should  be  powered  on 
prior  to  loading  MTWS.  There  are  three  types  of  computer 
terminal  that  are  used  in  an  MTWS  network  that  must  be 
present  before  an  MTWS  simulation  can  be  loaded  and  run. 

1.  MTWS  System  Control  (MSC) 

This  is  the  system  that  is  the  primary  interface  that 
is  used  to  create,  load,  and  control  MTWS  exercises. 

2 .  MTWS  Application  Network  (MAN) 

There  can  be  multiple  MAN  stations  on  an  MTWS  network, 
but  for  an  exercise  the  size  of  the  A2C2  scenario,  only  one 
is  necessary.  The  MAN  stations  control  the  actual 
simulation  of  the  scenario.  In  the  case  of  larger  exercises 
using  multiple  MAN  stations,  each  MAN  will  execute  a 
particular  set  of  computations  apply  to  specific  aspects  of 
the  scenario,  such  as  Air  operations,  ship-to-shore 
operations,  or  ground  movements.  The  MAN  stations  are 
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configured  through  the  MSC,  so  human  interaction  is  required 
with  the  MAN  terminal  except  to  power  them  on  and  off. 

3.  MTWS  Display  Station  (MDS) 

The  MDS  stations  are  the  primary  interface  between  the 
MTWS  simulation  and  the  participants  of  an  exercise.  Most 
exercises  will  use  multiple  MDS  stations  including  A2C2. 
The  MDS  station  displays  the  map  layout  of  the  scenario,  and 
provides  the  means  for  the  MTWS  operators  to  enter  commands 
that  direct  units. 

B .  STARTING  MTWS 

1.  Start  MSC 

The  user  needs  to  know  the  correct  user  ID  and  password 
to  log  on  to  the  MSC.  These  should  be  available  from  the 
local  network  system  administrator.  Once  the  MSC  is  logged 
on,  the  should  click  the  right  mouse  button  on  an  area  of 
the  screen  that  contains  no  windows  or  icons.  A  menu  will 
appear,  and  the  user  should  select  APPLICATIONS  ->  START 
SYSOP  ->  MTWS. 

Three  windows  will  appear  including  the  MTWS  Sys  Ops 
window.  In  this  window,  select  the  SYSTEM  CONTROL- >  ADMIN  - 
>  START  MSC  menu  option.  Wait  until  the  MTWS  Sys  Ops  window 
indicates  that  the  MSC  has  started. 

2.  Load  MAN 

In  the  MTWS  Sys  Ops  window,  select  SYSTEM  CONTROL  -> 
APPLICATIONS  ->  LOAD  MAN.  A  window  entitled  Man  Hosts 
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appears,  and  displays  all  the  possible  MAN  stations  that 
could  be  used.  For  A2C2  only  select  MAN001.  Press  the  OK 
button  in  the  MTWS  Sys  Ops  window.  Wait  until  the  MTWS  Sys 
Ops  window  indicates  that  the  MAN  has  loaded.  In  the 
meantime,  the  MAN  station (s)  should  automatically  logon,  and 
a  series  of  windows  and  icons  will  appear. 

C.  LOADING  OR  CREATING  AN  EXERCISE 

At  this  point  in  the  MTWS  loading  process,  the  user 
will  have  the  option  to  either  load  an  existing  scenario,  or 
create  a  new  one . 

1.  Creating  an  Exercise 

To  create  an  exercise,  select  the  EXERCISE  CONTROL  -> 
DATABASE  ->  EXERCISE  ->  CREATE  menu  option  in  the  MTWS  Sys 
Ops  window.  The  exercise  configuration  window  will  appear. 
The  user  should  enter  the  appropriate  information.  After  an 
exercise  has  been  created,  follow  the  procedures  in  the  next 
section  to  load  the  exercise. 

2 .  Loading  an  Exercise 

In  the  MTWS  Sys  Ops  window,  select  the  EXERCISE  CONTROL 
->  DATABASE  ->  EXERCISE  ->  LOAD  menu  option.  The  user 
should  wait  until  the  MTWS  Sys  Ops  window  displays  the 
message  saying  the  the  exercise  and  terrain  load  are 
complete . 

Next,  the  system  CONTROL  ->  APPLICATION  ->  START  APP 
menu  option  should  be  chosen  from  the  MTWS  Sys  Ops  window. 
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MTWS  will  display  a  message  when  the  application  has 
successfully  started.  At  this  point,  the  user  is  ready  to 
start  playing  or  configuring  the  MTWS  exercise. 
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